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ABSTRACT 


Traditionally,  the  design  and  l  Tiplementatlon  of  a 
conventional  database  system  beolns  vlth  the  choice  of  a 
data  model  followed  by  the  specification  of  a  model-based 
data  language.  Thus,  the  database  system  is  restricted  to  a 
slnnie  data  model  and  a  specific  data  language.  An 
alternative  to  this  traditional  approach  to  database-system 
development  is  the  multl-llngual  database  system  (MLOS). 
This  alternative  approach  affords  tne  user  the  ability  tn 
access  and  manage  a  large  collection  of  databases,  via 
several  data  models  and  tnelr  corresponding  data  lanouages, 
without  the  aforementioned  restriction. 

In  this  thesis,  we  present  a  metnodology  for  supporting 
networK  (CODASYL)  database  management  on  tne  wl,ds. 
Specif icallv,  we  design  an  interface  whlcn  translates 
rODASYli-Of*L  statements  Into  A60L  requests,  we  descrloe  tne 
data  structures,  the  control  mechanisms,  and  tne  functions/ 
procedures  necessary  to  Implement  such  a  system. 
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A.  MOTIVATIOV 

L/iirlm  the  cast  two  lecarles,  the  desl^in  and 
iopieoentation  of  dataoase  svste’^s  has  followed  a  rather 
nredlctaole  path.  The  sequence  of  events  In  toe  tyoical 
approach  has  oeen  to  decide  on  a  data  model,  specitv  a 
mode  1-hased  lanauaoe,  and  ultlinatelY»  develop  a  system  for 
controlling  and  executing  the  transactions  written  in  the 
data  lanquaoe.  This  approach  to  database  system  tievelor.ment 
has  resLiltea  in  an  abundance  or  homooeneoiis  natabase 
systems  eacn  of  wnlch  restricts  the  user  to  a  single  oata 
model  and  a  specific  model-based  data  manipulation  lanquaae, 
oome  examnies  of  systems  aevelooeu  using  this  anproach 
Include  tfiM's  Information  ’’anageinent  System  fi^s)  vnich 
supDorts  only  the  hierarchical  data  .iiodel  and  Data  Language 
T  (ht/i),  operrv  Unlvac's  Dus-lioo  wnich  supports  Just  the 
networK  data  model  and  th?  C'^riASlL.  Data  lanlbulation 
Languaoe,  and  Tn*i»s  SOL/oata  System  which  supports  solely 
Che  relational  data  model  and  the  Structured  English  huer'/ 
Language  (S3L). 

An  unconventional  aoproach  to  tne  proPlem  of  database 
management  system  d-velopment ,  referred  to  as  the  '’ultl- 
llncual  Catabase  Svstem  (hLf'S)  TP-f,  i),  elinlnates  the 
restrictions  mentioned  above.  The  MLoS  woulg  dive  the  user 


the  ability  to  access  and  manaqe  a  large  collection  of 
databases,  uslna  several  data  models  and  cnelr  correspondina 
data  lanotjages.  The  design  goal  of  the  oraject  Is  tne 

develoD-nent  of  a  system  tnat  Is  accessible  via  a 
hlerarchlcal/OL/I  interface,  a  reiatlonal/sgL  Interface,  a 
hetwor</COL.ASYL  Interface,  and  an  entl ty-reiatlonshlp/Oaniex 
Inrerface,  Such  a  system  would  function  as  If  It  were  a 
heterogeneous  collection  of  database  systems  Instead  of  a 
single  model,  single  language  system. 

Some  of  the  advantages  of  a  hLDS  are  the  reuseanllity  of 
database  transactions  developed  on  a  conventional  system, 
economy  and  effectiveness  of  hardware  upgrades  (since  we  now 
upgrade  just  one  system  instead  of  a  oumoer  of  different 
systems),  and  Its  ability  to  support  a  variety  of  databases 
Dullt  around  any  of  tne  well-known  data  models.  Thus,  there 
Is  aroie  motivation  for  developing  such  a  system  as  the 
VLOS, 

B.  TBfc;  SYSTEM  IIKGAKIZATIDN 

To  order  to  realize  tne  above  c»Daoii  I  ties ,  the 
must  re  suDoorted  by  an  underlying  database  system  that  Is 
ooth  fast,  efficient,  and  effective.  if  tnese  criterion  are 
rot  met,  tnen  toe  Interfaces  being  developed  for  the  mt.dS 
may  be  renderea  useless.  Hence,  It  is  important  that  tne 
Kernel  data  model  and  kernel  data  language  (the  underlying 
moiiel  and  language  for  tne  system)  be  supnorted  py  a  hign- 
performanee  ann  n Iqn-caoacity  dataoase  system!.  Currently, 


the  attribute-based  data  model  and  attribute-based  data 
lanquacje  are  the  underlyinq  model  and  lanquaae  of  a  svstem 
whicn  is  referred  to  as  the  ’^ultl-bacicend  Database  System 
C'^eoS),  In  this  section,  we  provide  an  overview  of  ootu  tne 
MLDS  and  tne  mbds  to  enhance  the  readers  understandlm  of 
the  entire  '•’ultl-Llngual  Oataoase  System, 
t .  ins  )iui&l-Li&sual  Uatabasa  Sustea 

Figure  1  Illustrates  the  complete  structure  of  the 
multl-llngual  database  svstem,  rne  user  Interacts  with  tne 
system  through  the  languane  interface  layer  (LILl,  using  a 
chosen  user  data  node!  (JOM)  to  Issue  transactions  written 
In  a  corresponding  model-based  user  data  language  (dDL), 
The  LIL.  routes  the  user  transactions  to  the  iternel  maoplno 
system  (<rs),  Tne  xms  then  cerforrs  one  of  two  possible 
tasks.  It  either  transforms  a  uo'^-basei  database  definition 
to  an  equivalent  database  definition  based  on  th*  kernel 
data  model  (Knvi;  or,  when  the  user  snecifies  that  a  ijDt, 
transaction  is  tr  be  executed,  it  translates  the  UOD 
transaction  into  an  equivalent  transaction  in  the  kernel 
data  languane  fKor,), 

the  first  task  Is  per  form  en  in  the  followlm  wav. 
The  K'-is  forwards  the  KDw  data  definition  to  the  kernel 
controller  (KC),  The  nc  then  sends  the  kD'<  database 
definition  to  the  kernel  database  system  (KDIl,  when  the 
KOS  Is  finished  with  orocesslna  the  KDu  database  definition. 
It  Informs  the  KC,  The  KC  then  notifies  tne  user,  via  the 
LTL,  that  the  database  definition  has  oeen  orocessed  ano 


tf'at  the  loading  of  the  database  records  '»’av  begin.  The 
second  tasic  Is  oerfortied  In  a  sliillar  fashion.  The  K«S 
sends  the  transactions  to  the  KC  which  In  turn,  sends  the 
transactions  to  tne  KhS  for  execution,  Jnce  the  execution 
Is  conolete,  the  kds  sends  the  results  In  the  KD’’  form  bacK 
to  the  KC,  The  KC  routes  the  results  to  the  xernel 
formatting  system  (KFS),  The  kf3  reformats  the  results  from 
the  KOM  form  to  the  UOm  form,  Tne  KFS  then  dlsplavs  tne 
results  in  the  correct  UDM  form  via  the  Liu, 


UDMi 


(  UDL 


UDM 

TDL 

LIL 

K.MS 

KC 

KFS 

KDM 

KDL 

KDS 


User  Data  Mode! 

User  Data  Language 
Language  Interface  Layer 
Kerne!  Mapping  System 
Kernel  Controller 
Kernel  Formatting  System 
Kernel  Data  Model 
Kernel  Data  Language 
Kerne!  Database  'vstem 


KDM 


Figure  l:  The  wultl^Llngual  Database  System  (’'Lhsi, 

The  four  modules,  LIL,  Ki^S,  KC,  and  KFS,  are 
collectively  Known  as  the  lAaaaasa  iolftciace.  Four 
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interfaces  with  similar  modules  are  required  for  the  four 
Interfacinq  user  models  and  lanquaqes  (l.e,,  relational/SOfj, 
hlerarchlcal/DL/I ,  networtc/COhASYL-D'^L,  and  entlty- 
relatlonshlo/OaDlex )  of  the  mlos, 

2.  Zbft  iiultl-Qacleead  Qatabaafi  S^staa 

The  multi-backend  database  system  was 
deslqned  to  overcome  the  performance  problems  and  upcrrade 
problems  associated  with  the  traditional  aporoach  to 
database  system  deslon.  This  aoal  was  realized  throudh  the 
utilization  of  multiple  backends  connectea  in  a  parallel 
fashion.  The  backends  have  identical  hardware,  replicated 
software,  and  their  own  disk  systems,  Tn  the  •niiltl-backend 
corf louratlon,  there  Is  a  backend  controller,  wnicn  Is 
responsible  for  suoervislna  the  execution  of  dataoase 
transactions  and  for  interfacinq  with  the  nosts  and  users, 
''■he  backends  perform  tne  dataoase  operations  witn  the 
database  stored  on  the  disk  system  of  the  oackends,  Tne 
controller  and  oackends  are  connected  oy  a  communications 
hus.  isers  access  the  svstem  throuqh  eitner  the  hosts  or 
the  controller  directly  (see  Fldure  2), 

Performance  qalns  are  realized  by  tncreaslnq  the 
pumrer  of  oackends.  If  tne  size  of  the  database  and  tne 
size  of  the  responses  to  the  transactions  remain  constant, 
then  Mqos  produces  a  reciprocal  decrease  in  the  response 
times  for  the  user  transactions  wnen  the  numoer  of  bacxends 
is  Increased,  On  the  other  hand,  it  the  number  of  oackonas 
is  increased  ororort lonal ly  with  the  increase  in  oataoase 


size  and  transaction  responses,  tPen  tne  mbds  produces 
Invariant  resoonse  times  for  the  same  transactions,  for  a 
more  detailed  olscusslon  of  mbds  tne  reader  Is  referred  to 
[Refs,  2  and  3], 


Backend  Store  1 


riqiire  2:  The  f'ultl-backend  Database  System  c^brsi. 

In  this  thesis,  we  Investigate  the  deslqr  of  a 
network  (f'pnASYij)  Interface  for  tne  hl.uo,  banerjee  r«ef,  tJ  , 
Provided  an  Initial  deslon  for  such  an  interface,  we  are 
extending  nls  work  and  adaptlno  it  to  suocort  tne 
requirements  of  the  >’Lns,  In  particular,  we  present  a 
specification  for  the  Kernel  mapoing  sYSteo  (K'iS)  tnat  will 


be  used  in  the  network  interface 


ve  also  nrovlaa  an 


Inpiementatlon  strateav  for  tne  icernel  controller  (t'C),  The 
other  t*»o  modules,  tne  Lll.  and  the  KFS  are  nearly  the  sa;T)e 
in  structure  as  those  already  implemented  tor  the  DL/T  and 
SOL  interfaces,  and  thus,  they  will  not  be  discussed  In 
detail  in  this  thesis.  The  reader  is  referred  to  IRefs,  5 
and  b]  for  further  details  on  tne  design  of  these  modules. 

rnroughout  this  thesis,  we  will  make  extensive  use 
of  the  Suppllers-and-Parts  sample  dataoase  used  ty  oate 
[Ref,  71  for  illustration  of  our  work,  me  data  structure 
diaoram  for  f-ls  network  is  snown  In  Figure  3,  There  are 
suDPller  records  (S),  parts  records  (P),  and  shipments  (SP) 
records,  Tne  sets  of  the  database  are  suopilers-shipments 
(S-SF)  and  barts-shlpments  (P-SP), 


4> 

I  suoDiiers  I  I  parts  I 


(  S-SP  1  (  P-SP  ) 


I  snipments  1 


Pirjure  3;  Data  Structure  Diagram  of  the  Sarnie 
Supplier s-and-Parts  Database, 

In  Cnaoter  2,  we  orovide  a  descrlntlon  of  both  the 
network  (ClOftSYL)  data  model  and  the  attribute-based  model, 
as  well  as,  their  associated  data  languages.  In  Chapter  J, 
a  methodolouv  for  manpipg  a  network  (CODASYL)  database  Into 
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an  attribute-based  database  Is  presented,  Chaoter  4  is 
aedicated  to  exolalnlnq  the  data  mant^ulatlon  language 
translations.  And,  In  Chanter  5,  we  provide  iTiole'^entatlon 
condlderatlons  for  both  the  k^aS  ana  the  KC,  Finally,  In 
Chapter  6,  we  maxe  our  conclusions  aoout  the  proposed 


deslcn 


II.  ZUS  QAIA  ::Q0£L3 


Trie  choice  of  a  kernel  data  model  and  a  corresoondino 
kernel  data  language  Is  of  vital  Importance  In  developing  a 
multi-lingual  database  system.  The  kernel  data  model  and 
the  kernel  data  language  must  be  capable  of  supoorting  all 
the  necessary  data  model  transformations  and  data  language 
translations  required  by  the  '^LDS  language  Interfaces. 

It  is  our  intention  In  this  chapter  to  provide  a  summary 
description  of  the  data  models  related  to  the  network 
(COOASYL)  interface,  namely  the  COhASYL  data  model  ana  the 
attribute-based  data  model,  A  conceotual  view  of  ootn 
models  will  be  presented  along  with  a  orlef  discussion  of. 
the  data  manipulation  languages  associated  with  each  model, 

A.  THt  nOASYL  DATA  ’‘OPEL 

In  general,  the  network  (CODASYL)  data  model  Is  eased  on 
the  concept  of  directed  araons,  Tne  modes  of  the  grenns 
usually  represent  entity  tvpes  which  are  described  oy 
records,  »hile  the  arcs  of  the  grachs  correspond  to 
relationship  types  that  are  represented  as  connections 
between  records.  The  CODASYL  (Conference  on  Data  system 
Languages)  data  model  is  referred  to  ov  Tslchritzls  and 
Locnovsky  (Ref.  R:pc,  as  the  most  comprehensive 
specification  of  a  network  data  model  that  exists.  Tn"s.  the 


reason  for  choosing  the  COOASYL  iata  ■nodal  and  Its  data 
n'anloulatlon  language  for  tne  networic  interface  of  the  mlds, 
1.  A  CaQceBl.ual  Ulsis  oX  tna  liAdAl 

CDOASYL  databases  are  nef-»orics  of  record  types  and 
set  tyoes,  where  records  and  sets  are  tne  entitles  which 
describe  the  databases.  A  record  type  in  a  CODASYL  database 
is  defined  in  [Ref,  4]  as  a  collection  of  hierarchically 
related  data  Item  names  or  field  names.  These  field  names 
are  specified  In  a  schema  declaration  [template)  for  tnat 
record  tyoe,  A  cftcotd  is  any  occurrence  of  a  record  type  and 
has  specific  values  assigned  to  the  data  items  named  in  the 
schema  declarations.  This  Imoiies  that  a  record  type  Is 

slmciv  a  generic  name  for  all  of  tne  records  tnat  are 

described  by  toe  same  template. 

Set  tyoes  in  a  CODASYL,  database  indicate 
relatlonsblos  between  record  tyoes,.  They  consist  of  a 
single  record  type  called  tne  avaec  record  type,  and  one  or 
more  record  tyres  called  the  aftabas  record  types.  Thus,  a 
set  tvoe  exoresses  explicit  associations  between  different 
record  tvnes  in  the  database.  This  characteristic  maices  it 
Possible  for  a  designer  to  model  a  lane  varietv  ot  real 

world  database  management  problems  involving  diverse  record 
types,  df  soeclal  Imoortance  nere  is  toe  fact  that  th'i 

owner  record  type  of  a  set  tvoe  is  oroniDlteg  from  being  a 
irember  ot  the  sane  set  tyoe, 

Set  tyoes  nave  occurrences  lust  as  record  types  oo. 


F.ach  occurrence  ot  a  set  tvoe  has  one  occurrence  of  tne 


owner  recor'i  tvoe  and  zero  or  more  occurrences  of  each  o^ 
Its  member  record  tyoes.  The  prohibition  here  is  that  a 
record  occurrence  cannot  be  oresent  in  two  different 
occurrences  of  the  same  set  type.  This  duailf icatlon 
emphasizes  the  pairwise  disjointness  of  set  occurrences  of  a 
qlven  set  type.  Figure  4  gives  an  example  of  a  set 
occurrence  for  the  set  tyoe  S-SP  of  our  samole  iataoase. 

As  can  be  seen  from  the  example,  tne  CCnA?YL  data 
model  makes  tne  design  of  a  database  quite  simple.  However, 
keeping  trac<  of  all  of  the  relationships  can  oe 
considerably  involved.  Thus,  one  of  our  primary  concerns  in 
the  design  of  a  CDDASYL  language  interface  for  the  mLns  is 
to  preserve  these  relationships  without  the  complexity, 

S  Can  owner  record  occurrence) 

I  S2  I  Jones  I  10  I  Paris  I 

(a  set  occurrence) 

(S-SP) 

(two  member  record  occurrences) 

SP  SP 

^  m  mm  mmmmmmm  mmmm  m 

t  52  I  PI  I  300  I  I  52  I  P2  I  4oO  I 

Figure  4;  A  CODASYL  Set  Occurrence, 

2.  liae  Data  :iaalaulallaa  La&auase  (CCQilS£L-c::L) 

rOD ASYTi-Pdi.  is  a  procedural  data  language.  The  user 
of  a  COhasyl  database  writes  his  programs  in  a  neneral 
nurnose  language  that  hosts  the  rOPASYri-Phri,  In  general. 
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most  ooeratlons  In  a  COOASYL  database  are  carried  out  by 
"naviqat Inq"  through  set  occurrences.  The  starting  oolnt 
for  this  navioatlon  is  usually  the  current  record  of  the  run 
unit.  The  sua  uait  is  the  application  program  Ctransaction) 
belno  executed,  A  full  exoianatlon  of  currency  win  be 
provided  later  in  the  thesis.  Other  PmIj  operations  can  be 
based  on  the  current  record  occurrence  of  a  set  tyoe  or 
record  type, 

CnhASYL-PvL  has  several  primary  operations  wnlch 
support  the  primary  database  operations  of  retrieval. 
Insertion,  deletion,  and  modification  (uodatino  existlno 
records),  nifferent  Imoiementatlons  orovide  varying 
collections  of  these  ooeratlons,  hut  we  will  concentrate  our 
discussion  on  the  basic  ones. 

The  cornerstone  of  the  COOASYL-Ddb  is  the  r’lhh 
statement,  Tnls  statement  is  used  to  estaoilsh  the  currency 
of  tne  run  unit,  and  optionally  used  to  estaollsn  the 
currency  of  the  set  type  and  the  recoro  tyoe,  Tne  oeneral 
format  of  the  FliJD  statement  Is 

Flijn  record-selectlon-exoresslon  [  )  , 

where  the  sduare  hracicets  contain  optional  expressions  for 
tne  suDPresslon  of  updates  to  the  currency  indicators.  In 
mtner  words,  we  may  suppress  the  updating  or  tne  currency 
for  a  record  type,  a  set  tvoe,  or  both.  The  record- 
selection  -expression  has  several  different  forms  cacn 


'Jesianed  to  access  a  particular  record  In  three  different 
ways,  either  out-of-the-blue  without  reference  to  a 
previously  accessed  record;  relative  to  a  previously 
accessed  record;  or  by  repetition,  Ihe  other  D**L  statements 
are  somewhat  less  extravanant. 

The  GKT  statement  in  CODASYI.-DML  complements  the 
PTND  statement.  Once  a  record  is  found,  the  GKT  statement 
Places  the  recoro  In  the  transaction's  worKlnq  area  for 
access  oy  tne  transaction.  There  are  two  basic  formats  for 
the  Gt.T  statement.  They  Include  GET  record. tyoe,  vhich 
dives  the  transaction  access  to  the  entire  record,  and  GET 
items  I  record. type,  which  gives  access  to  only  reauested 
data  Items  In  the  record  tyre. 

The  STOR?:  statement  Is  used  to  oiace  a  new  record 
occurrence  into  the  database.  The  proorammer  must  builo  uo 
an  Image  of  tne  record  orlor  to  the  STORE  reouest  using 
assignment  statements  whlcn  are  a  oart  of  the  nost  language 
in  which  the  CnnASYO-OML  is  embedded.  Once  the  record  Imaae 
has  been  created,  then  the  proper  set  occurrence  for  the 
record  must  be  selected  by  the  database  management  system. 

The  set  occurrence  in  wnich  the  new  record  is  stored 
is  determined  by  the  SET  SEOECTTOm  clause  specified  in  tne 
schema  definition  for  the  oolect  database.  The  three 
options  available  are;  BY  afpmcatTQN,  wnich  means  that  tne 
application  nrogram  { transaction)  is  responsible  for 
selecting  the  correct  occurrence;  BY  vaLiHE,  wnich  means  the 
system  selects  the  oroper  occurrence  based  on  data  item 
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values  SDCClfic  to  the  owner  of  the  set  occurrence  desire'i; 
and,  bY  STRaCTMRAL,  which  oieans  tnat  tne  systen  selects  an 
occurrence  oy  locatlno  the  owner  record  with  a  soecltlc  Item 
value  eo'ial  to  the  value  of  that  same  Item  in  tne  record 
belnq  stored.  The  restriction  on  tne  last  two  options  is 
that  the  data  items  being  used  must  nave  been  soecified  wltn 
D'lPMCAf^s  ‘107  ALLOWED  in  the  schema  definition,  A  detailed 
discussion  of  syntax  for  tne  COOASYL-D^L  is  presented  later 
in  the  thesis. 

If  the  user  transaction  desires  to  mantiallv  insert 
records  into  the  database,  two  reauiremants  exist.  First, 
the  schema  definition  most  Include  tne  InSc.PTION  ID  manual 
clause  In  tne  set  desclotlon  tor  this  oarticuiar  memner 
record.  Then  the  cori'')KrT  statement  is  used,  instead  of  tne 
FTOf^E  statement,  for  insertion  of  the  record  Into  tne 
nataoase.  The  roeorn  to  he  inserted  is  the  current  record 
of  tne  run  unit.  The  set  occurrence  in  whlcn  the  record  is 
inserted  Is  determined  In  the  same  wav  as  the  STORE 
statement, 

mere  is  also  a  statement  in  th?  CODADYL-D^t.  »hicn 
oerforms  the  opposite  ooeration,  namely,  tne  manual  removal 
of  a  record  occurrence  from  a  set,  The  DIoraNNCCT  statement 
oerforms  this  operation,  it  disconnects  the  current  record 
of  the  run  unit  from  the  occurrence  ot  the  soecified  set 
that  contains  the  record.  The  record  occurrence  still 
resides  In  tne  database,  out  it  Is  no  lonaer  a  member  of  tfie 
soecified  set,  Tnere  Is  a  ouallf icat Ion  involved  with  this 
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statcfnent,  no-(ever.  The  record  to  te  disconnected  '»'ust  have 
a  RETE'^TION  clause  of  OPTinNAL  In  tne  -nemoer  descintion  tor 
the  set  tyoe  definition  In  the  schema. 

In  order  to  delete  records  from  a  CnDASYL  datanase, 
the  ERASE  .<-tatement  Is  usea.  There  are  four  basic  options 
to  this  statement;  however,  two  of  tnem  are  very  complex  and 
maroinally  useful,  so  they  will  not  be  discussed  in  this 
thesis,  '^he  simplest  of  the  two  we  win  deal  witn  Is  tne 
E'^ASE  without  the  ALfi  ootion,  Tnls  statement  causes  the 
current  record  of  tne  run  unit  to  be  deleted  from  tre 
dataoase  if,  and  only  If,  it  is  aot  the  owner  of  a  non-empty 
set.  If  It  Is  the  owner  of  a  non-emotv  set,  the  erase 
falls, 

Tne  ERASE  ALL  option  is  a  little  less  useful 
accordlnq  to  Olle  [Ref,  0],  This  statement  causes  the 
current  record  ot  the  run  unit  to  he  deleted  whether  or  not 
it  is  the  owner  of  a  non-empty  set.  Additionally,  this 
oDtlon  causes  each  member  record  of  the  set  to  oe  oeieted, 
and  if  thev  too  are  owners  of  non-emocw  sets,  tneir  menbers 
are  deleted.  Inis  action  continues  all  tne  way  down  tne 
rierarchv.  As  one  can  see,  an  entire  dataoase  could  be 
destroyed  If  tne  user  Is  not  careful  wnen  uslnq  tnis  option. 

The  final  statement  to  be  covered  in  this  thesis  is 
the  woDIFl  statement,  it  is  used  to  modify  values  of  data 
items  in  a  record  occurrence.  This  includes  modlfvinq  all 
data  ite-"S  or  anv  sunset  of  the  data  items  in  the  record 
tyne,  Tt  may  also  be  used  to  channe  the  memoershlo  of  a 


record  occurrence  iron  one  set  occurrence  to  anotner,  as 
Iona  as.  they  are  of  the  same  set  type.  Thus,  i»e  nave  our 
oaslc  woriclng  set  of  DML  statements. 

D.  THE  ATTSIBUTE-BASED  hATA  MODEL 

The  attribute-based  data  model  was  originally  described 
by  Hsiao  [Hef,  10],  it  is  a  very  simple  but  oowerful  data 
model  capable  of  representlnq  many  other  data  mooels  witnout 
loss  of  information.  It  is  this  simplicity  and  universality 
that  makes  the  attribute-based  model  the  ideal  choice  as  the 
kernel  data  model  for  the  mld^,  and  the  attribute-based  data 
language  (ABDL)  as  the  kernel  language  for  the  system, 

1.  k  CaacfiQlual  at,  ta&  Uadal 

The  attribute-based  data  model  is  eased  on  the 
notions  of  attributes,  and  values  for  these  attrlbiites.  An 
attribute  and  its  associated  value  is  therefore  referred  to 
as  an  at&cluute-ualua  Dais  or  ksuiio&d.  These  attrlnute- 
value  Pairs  are  formed  from  a  Cartesian  product  of  tne 
attribute  names  and  the  domains  of  the  values  for  tne 
attributes,  Uslno  this  approach,  any  logical  concept  can  oe 
represented  by  the  attr loute-based  model, 

A  sacasd  ,  In  the  attribute-based  model  represents  a 
logical  concept.  In  order  to  specify  tne  concent 
thoroughly,  keywords  must  be  formed,  A  record  then.  Is 
slmplv  a  concatenation  of  the  resultant  keywords,  sucn  that 
no  two  keywords  in  the  record  have  tne  same  attribute. 
Ado  It ional 1 V ,  the  model  allows  for  the  inclusion  of  textual 


inf or'T\atlon ,  called  tne  cacatd  bfidit  ,  in  tne  for*  of  a, 
possibly  empty,  string  of  cbaraeters  describing  tbe  record 
or  concept.  The  record  booy  is  not  used  for  search 
purooses,  figure  5  gives  tne  for!^at  of  an  attr ioute-oased 
record. 

(Ottrlbutel  ,valuel>,  ...  , 

<ar tributen , valuen>, 

{  text  }) 

figure  5:  An  Attribute-eased  Pecord 

The  anoied  nrackets,  <»>,  are  used  to  enclose  a  iceyword 
•jxhere  the  attribute  is  first  followed  by  a  comma  and  then 
the  value  of  the  attribute.  The  record  oody  Is  tren  set 
aoart  oy  curly  bracicets,  {,>.  Tge  record  itself  is 
identified  by  enclosure  within  parentheses.  As  can  be  seen 
from  the  aoove,  this  is  auite  a  slmrie  wav  of  representing 
information , 

In  order  to  access  the  database,  the  attribute-based 
model  emoloys  an  entity  called  predicates,  A  Keyword 
Predicate,  or  simply  ascdicatc  ,  Is  a  triple  of  th*  form 
(attribute,  relational  operator,  value).  These  oredleates 
are  then  combined  in  disjunctive  normal  form  to  oroduce  a 
aufiau  of  tne  database.  In  order  to  satisfy  a  oredlcate,  the 
attribute  of  a  Keyword  ip  a  record  must  be  Identical  to  the 
attribute  In  the  predicate.  Also,  the  relation  specified  ov 
the  relational  operator  of  the  predicate  oust  hold  between 
the  value  of  the  predicate,  and  the  value  of  tne  Kevword,  a 


record!  satisfies  a  query  If  all  predicates  of  the  query  are 


satisfied  bv  certain  <evwords  of  the  record,  A  query  of  two 
predicates 


(Typp;  S  S)  and  (SNO  a  S4) 

would  be  satisfied  by  any  record  of  rYPC  S  (supplier  tvne) 
whose  Sf;q  (supplier  number)  is  S4,  and  It  would  nave  tne 
form, 

Cottrlbutel  ,vauel>,  ,<TYPE,S>,  ...  , 

<SN0,S4>,  ...  ,<attrlbuten,valaen>,  (text) ) . 

2.  Caia  Laaauaae  (^aCL) 

The  ABOT4  as  defined  by  Panerjee,  Mslao,  and  Kerr 
(Ref.  11)  was  orlqlnallv  oevelooed  for  use  with  the  Database 
Computer  (DflC).  This  ianquaqe  is  the  kernel  lanquaqe  used 
in  the  '^LDS,  Tne  ALijL  supports  the  five  primary  natabase 
operations,  INSERT,  DELETE,  UPDATE,  RETRIEVE,  and  RtTRIEVE- 
Those  of  use  to  us  in  this  portion  of  the  '’LOS  work 
However,  are  insert,  delete,  UPtaTE,  and  retrieve.  a  user 
of  this  ianquaqe  issues  either  a  request  or  a  transaction. 
A  Laaua&t  in  the  abdl  consists  of  a  primary  operation  with  a 
qualification.  The  auailllsallofi  specifies  tne  portion  of 
the  database  that  Is  to  be  ooerated  on,  when  two  or  more 
requests  are  qrouped  toqetner  and  executed  sequential Iv,  we 
have  a  &sao&ac£10B  in  the  AdOL,  There  are  four  types  of 


requests , 


corresoondlnq  to  the  four  orimary  database 


operations  listed  above.  They  are  referred  to  by  the 
same  names. 

Records  are  Inserted  Into  the  database  with  an 
INSERT  request.  The  qualification  for  this  request  Is  a 
list  of  icey words  and  a  record  body.  Records  are  removed 
from  the  database  by  a  DELETE  request.  The  qualification 
for  this  request  Is  a  query, 

when  records  In  the  database  are  to  oe  modified,  the 
UPDATE  request  is  utilized.  There  are  two  parts  to  the 
qualification  for  this  request.  They  are  the  query  ana 
modifier.  The  query  specifies  the  records  to  be  modified 
while  the  modifier  specifies  how  tne  records  are  to  oe 
mooif ied. 

The  final  request  to  be  mentioned  here  Is  tne 
RETRIEVE  request.  As  Its  name  Imolles,  it  retrieves  reeoras 
from  the  database.  The  qualification  tor  this  request 
consists  of  a  query,  a  tardet-list,  and  an  ootlonal  by¬ 
clause,  The  query  specifies  the  records  to  oe  retrieved. 
The  tarqet-list  contains  the  outout  attributes  whose  values 
are  required  by  the  request,  or  it  may  contain  an  apareqate 
ooeration,  l,e,,  AVG,  COUNT,  SUM,  mlN,  “AX,  on  one  or  more 
output  attribute  values.  The  oy-clause  is  optional  ani  Is 
used  to  orouD  records  wnen  an  aopreqats  ooeration  is 
specified. 

As  indicated,  A«DL  consists  of  some  verv  simple 
database  ooerations.  These  operations,  nevertneless ,  are 
caoaoie  of  supportlnq  comolex  ano  comorehensive 


transactions 


Thus,  A8DL  meets  the  requirement  of  capturlno 


all  of  the  orlmarv  operations  of  a  iatabase  system,  and  Is 
quite  useful  for  our  ourooses.  Figure  6  snot^s  examples  of 
the  four  primary  abol  requests, 

I.'ISERT(<TYPF,SP>,<SNC,S2>.<PNO,Pl>,<JTY,3rtO>,  (sampleM 
L)ELFTE(CTypE  =  S)  and  (SNQ  a  S4)) 

UPOATE((TYPE  =  SP)  and  (PNO  a  Pl))(,3TY  s  QTY  ♦  100) 
RF.rRIEVEt  (TYPE  a  b)  and  (PNAHE  a  Nut)) 


Figure  6:  Sample  ABDL  Requests 


III.  u£x;aQ&i[k  (cq&&sxl)  is  &xxaiaux£-2&s£&  qax^ 


Oslnq  a  modification  of  a  procedure  orlolnally  outlined 
by  flanerjee  [Pef,  4],  the  transformation  of  networK  data 
Into  attribute-based  data  becomes  a  relatively  simole  tasic. 
The  data  ^ust  be  transformed  Into  records  wnich  consist  of  a 
set  of  var lable-lennth  attribute-value  oalrs  and  a  record 
body.  The  attribute-value  oalrs  mav  reoresent  the  tyne, 
quantity,  or  characteristic  of  the  value,  and  the  record 
body  is  as  described  in  the  previous  chapter.  Additionally, 
all  attributes  in  tne  attribute-based  records  are  distinct, 
for  looical  reasons. 

The  itey  aspect  of  the  mapoina  process  Is  the  retention 
of  the  cnhASYL  notions  of  records  and  sets  Cthe  llnoaes 
anonq  records),  ’'•e  emphasize  that  tne  COoASYL  notions  of 
records  and  sets  are  act  the  same  as  the  attribute-based 
notions  of  records  and  sets.  Thus,  tne  maoplnq  algorltnm 
presented  nerein  uses  attr Ibute-pased  constructs  Cor 
notions)  to  Implement  tne  cnpASYL  notions.  in  the  foliowlno 
sections,  -ve  present  tne  various  entitles  uipich  must  oe 
■napoed,  their  cor resoondlnq  attrlnute-oaseo  eaulvaient,  and 
an  exanole  of  tne  maoplnq  process  using  our  sample  database. 
It  Should  be  clear  after  tnls  description,  that  tne  COhASKL 
notions  of  records  and  ttielr  relationships  are  indeed 
preserved  in  tne  attrloute-nased  system. 


ft,  THE  REPRESE'ITATION  QF  A  CQDA5YL  RECORD 

A  CQOASYL  record  tyoe  is  structured  as  a  hierarchical 
confiauration  of  data  items  such  as  depicted  in  .Figure  7Ca), 
t*here  Rl  is  the  record  name,  and  A,  a,  C,  D,  E,  and  F 
represent  data  item  names.  Figure  7(d)  snows  an  occurrence 
of  record  Rl,  Notice  that  only  the  values  of  the  data  items 
are  present  in  the  C00A3YL  record.  In  the  attr Ibute-oaseri 
system,  both  the  data-item-name  ana  its  value  are  stored  in 
the  record. 


t  i 


Record  Rl 

01  A 
01  3 

02  C 
02  D 


03  E 
02  A 


01  F 


Record  ftl 

aOl-value 
bOl-value 
c02»vdlue 
d02«value 
e03«value 
a02.valU9 
f 01 .value 


Figure  7j  Hierarchical  Structure  of  a  CODftSYL  Record, 

Thus,  in  order  to  capture  the  cgoASYL  information ,  <ey^ords 
must  re  created  for  each  of  the  elementary  data  Hems 
included  in  the  CUFASYL  record.  These  data-ltem  Keywords 
should  be  of  the  form 


t  4 


L. J 

•  -  •  .  V 

»  ^  ^ 

c:i 


<  data_ltem.name,data.ltem.value  > 


where  the  data-item-name  is  Qualified  bv  data-ltem-rames  at 
a  higher  level  if  it  Is  not  unique.  Figure  R  shows  the  data 
item  reoresentation  for  toe  CiJOASYL  record  of  Figure  7, 


5^ 
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(...»<  A,a.value  >,<  B,b. value  >, 

<  C,c„value  >,<  0, devalue  >, 

<  E,e. value  >,<  d. A, b. a. value  >, 

<  F,f.value  >,,..) 


Figure  8:  Attrlrute-Based  Keorasentatlon  o£ 
CODASYL  Data  Items. 


The  dots  at  the  beoinninq  of  the  record  and  the  dots  at  the 
end  of  the  record  indicate  that  there  are  additional 
keywords  qenerated  for  the  record  In  order  to  ©reserve  the 
CODASYL  record  information.  These  additional  keywords  are 
explained  as  follows, 

tach  record  occurrence  in  a  CODASYL  database  must  also 
belonq  to  a  oarticular  type.  This  implies  tnat  a  keyword 
Indlcatlnq  record  type  must  also  be  included  In  the 
.  attribute-based  record.  Its  format  is 

<  TYPE,record»tYPe  > 

where  TYPE  Is  a  literal, 

I 

Finally,  each  record  occurrence  of  a  CODASYL  database 
has  a  dataoase  key  (or  aadress)  qenerated  for  it,  Tnus, 
there  Is  a  requirement  for  representation  of  this  value  as 
well  in  the  attrlbute-basea  record,  Tne  follow  Inn  form  is 
used  for  this  keyword,  where  OBKEY  is  a  literal, 

\ 


<  DBKEY, dataoase.key  > 


So,  in  representing  record  information,  «ie  nave  the  need 
for  tnree  mandatory  keyword  types,  namely,  data. item. name, 
with  or  without  qualification,  TYPE,  and  DBKEY, 

B,  THE  REPRESENTATION  OF  CODASYL  SETS 

In  order  for  the  attr loute-based  record  to  be  complete, 
it  must  also  include  information  related  to  COOASYt,  set 
membership,  and  set  orderlno.  Since  occurrences  of  set 
tvpes  are  oalrwlse  disjoint,  then  each  memoer  record 
occurrence  nelopdirg  to  a  set  occurrence  is  also  identified 
py  its  owner  record  occurrence.  This  means  that  we  can 
express  set  membersnip  by  inclusion  of  tne  keyword 

<  MEMBER, set. tyoe.owner.database.icey  > 

for  each  set  occurrence  in  which  the  recora  is  a  member. 

Finally,  tne  logical  position  of  a  record  occurrence 
within  a  sot  occurrence  Is  often  useful.  Thus,  orderlna  of 
i^emoer  record  occurrences  witnin  a  set  occurrence  is 
expressed  oy  Inclusion  of  tne  keyword 

<  posiTin?*,  set. type,  sequence-number  > 

In  the  attr loute-based  record  tor  eacn  set  in  wnirn  tne 
record  Is  a  memner  record. 

Therefore,  in  reoresentlno  set  information,  -e  nave  tne 
need  for  two  kevword  tyoes,  those  representing  r-mrer 
records,  and  tnose  representing  memner-record  positions 


within  sets 


c 


A  COMPLETE  DATA-MAPPING  EXAMPLE 


As  orevlously  fnentloned,  by  utlllzlnq  tne  ^bove 
transformation  scneme,  we  can  take  an  existing  COuASYL 
database  and  transform  it  into  an  attribute-based  database 
witnout  any  loss  of  information  related  to  tne  CDOASYL 
records  and  sets  (l,e,,  record  reiatlonsnlps) ,  The 
transformation  should  therefore  result  in  records  of  the 
form  shown  in  Figure  9, 


(<  TYPE, record. type  >,<  hRKFY, database. key  >, 
<  data. item. namel , data. Item. valuel  >, 


<  data. item. namen, data. item. valuen  >, 

<  .^FMAER, set. typel  .owner. database-keyl  >. 


<  mfmper, set. tyoeo, owner. database. keyo  >, 

<  POSITION , set. typel , sequence. number  >. 


<  Rn.siTIGN ,  set. tyneo ,  sequence. number  > 

<  textual  Information  >) 

Flqur*  9;  An  Exaxnie  of  a  Transformed 
CQPASYL  Record. 


« 


SCHEM^  NAME  IS  SUPPLIERS.ANO.PARTS , 
RECORD  NAME  IS  S; 

DUPLICATES  ARE  NOT  ALLOWED  FOR  SNO, 


SNQ 

SNAME 

STATUS 

CITY 


TYPE  IS  CHARACTER  5. 
TYPE  IS  CHARACTER  20, 
TYPE  IS  FIXFD  20, 

TYPE  IS  CHARACTER  15, 


RECORD  NAME  IS  P; 

DUPLICATES  ARE  NOT  ALLOWED  FOR  PNO, 


pilO 

PNAME 

COLOR 

WEIGHT 

CITY 


;  TYPE  IS  CHARACTER  6, 

;  TYPE  IS  CHARACTER  20, 

;  TYPE  IS  CHARACTER  6, 

;  TYPE  IS  FIXED  4. 

;  TYPE  IS  CHARACTER  15, 


RECOHO  NA‘=E  IS  SP; 

DUPLICATES  APE  NOT  ALLf)Ww:D  FOR  SNO,  PNO. 
SNO  ;  TYPE  IS  CHARACTER  5, 

PNG  ;  TYPE  IS  CHARACTER  6, 

QIY  ;  TYPE  IS  FIXED  5, 

SET  NAME  IS  S.SP; 

OW'igH  TS  s; 

ORDER  IS  SORTED  BY  DEFINED  KEYS 
DUPLICATES  ARE  NOT  ALLOWED, 

ME'^BER  IS  SP; 

IVSERTION  IS  AUTO’fATIC 
RETENTION  IS  FIXED; 

KEY  IS  ASCENDING  PNO  IN  SP; 

SET  SELECTION  13  my  VALUE  UF  SwO  IN  S, 

SET  NAHE  IS  P.SP; 

OWNER  IS  p; 

ORDER  IS  SORTED  BY  OFFTNEP  KEYS 
OIIPLICAIES  ARE  NOT  ALLOwEL, 

‘'EM3ER  IS  SP; 

I  JSERIION  IS  AIJTn«ATIC 
HETEMIun  IS  FIXED; 

KEY  IS  ASCE''OING  SNO  Ifl  SP; 

SET  SELECTICM  IS  BY  ViVLl'S  OF  PNG  p. 

Fl^jure  to:  scP**ma  for  the  Suopliers-end-Partg 
Lararase, 


In  orHer  to  demonstrate  the  transformation  process 
further.  Figure  IP  above  provides  the  schema  detlnltioo  for 
our  samole  Suopi lers-and-Parts  database,  uslm  this  schema 


definition,  the  CODASYL  record  occurrences  of  Flaure  11  ere 


transformed  Into  the  attr loute-hased  records  of  Fljure  12. 


s 

I  S2  I  Jones  I  1')  I  Paris  I 

4.... ................... ...4. 

P 

I  PI  I  Nut  I  wed  I  12  I  London  l 


SP 

I  S2  I  PI  I  300  I 

Floure  11:  Sample  Record  Occurrences  from  the 
Suppllers-and-Parts  Database, 


(<TYPE,S>,<D»KFY, 1>, 

<SN0,S2>,<SNA‘'E,  Jones>, 

<STATUS, 10>,<CITY,?arls>, 
i  Sample  supplier  record  >) 

(<TYPe,P>,<LHKF:Y,2>, 

<nLO,Pl>,<PNAMR:,Utit>, 

<C0LOR,Red>,<wEIc;HT  ,12>, 

<CITY , London> , 

{  Samole  oarts  record  >) 

r<TYPe,SP>,<|-)nKEY,  3>, 

<soa,s2>,<p  ui,pi>, 

<0TY,300>, 

<  'EMdKR,S»SP, 1>, 

<PC3I riQN.S.SP, 1>, 

<P0SITI0N,P_S?, 1>, 

{  Sample  5P  record  -here  the  record 
oelopcjs  to  t'*o  different  sets  >) 

Figure  12;  Attribute-Based  Eaulvalent  of  Record 
occurrences  In  Flaure  li. 


37 


IV 


iASfiiufi  ccua:»:£L-cul  HkiziiZ'dii  12  scsuaaia 


Having  demonstrated  how  networK  databases  can  oe 

successfully  transformed  into  attrlbute-baseo  databases.  *>€ 
are  now  ready  to  examine  the  maoping  of  netwerx  data 
manipulation  statements  Into  ABhtj  requests.  As  mentioned  in 
Chapter  2,  the  CODASYL  data  manipulation  lannuaqe  will  be 

used  for  tne  mlDo  network  interface.  It  snoula  oe  noted 

here  though,  that  only  a  subset  of  all  tha  available  Ofih 
statements  will  oe  used  in  the  mlus  network  interface. 
Specifically,  the  following  CCDASYt  statements  win  be 

incoruoratei  in  this  stage  of  the  project:  FI*'D,  CET,  arone, 
cn-ikKCT,  nrscONMKcT,  frasf,  anu  •‘noifY,  (if  tnese,  only  tne 
useful  formats  were  considered  for  tne  “^LOS,  it  should  oe 
further  noted  that  the  syntax  tor  these  various  statements 
was  derived  from  the  syntax  cresenteo  oy  hate,  Olle,  and  the 
original  CCOasyL  report  CFefs,  7,  anJ  12],  respectively. 
In  this  section  we  discuss  each  of  tne  above  statements 
and  their  associated  marolho  process.  Prior  to  describing 
tne  maocinn,  nowever,  we  first  exolaJn  the  notion  of 
currency  in  a  CODASYf,  database,  and  introduce  the  data 
structures  that  are  necessary  to  carry  out  tne  maooino 
process.  Toe  Appendix,  the  h.''S  (Kernel  daoDlno  System) 
soeclflcatlon,  gives  a  detailed  loo<  at  tne  maopino  process 


and  the  soeclfic  algorithms  aoplied  to  accomplish  the 
language  translations, 

A.  THE  MOTTO‘1  OF  CURRk.WCY 

In  general,  the  above  data  manipulation  statements  can 
be  grouped  into  two  categories,  data  retrieval  statements 
and  data  updating  statements.  However,  tne  common  thread 
between  the  two  groups,  as  well  as,  tne  inglvidual 
functionality  of  each  statement,  Heoends  quite  heavliv  on 
the  notion  of  CULS&CCU  among  the  records  and  sets  of  the 
ConASYL  database. 

The  concept  of  currency  in  a  CODAsyl  database  can  ne 
compared  to  the  well  Known  concept  of  current  position  in  a 
file.  The  Idea  here  is  that  for  each  application  oronram 
being  run  on  the  system,  a  table  of  •’currency  indicators"  is 
maintained.  In  general,  tne  currency  Indicator  is  an  object 
whose  value  is  a  database  beu<  it  serves  as  a  "cursor" 
which  Points  to  either  a  record  or  a  set  under  consideration 
by  the  acoiicatlon  program.  Database  Kevs  arc  values 
generated  pv  the  database  management  system  that  unlgueiv 
Identify  each  Indivinual  record  in  tne  database. 

Toe  currency  indicator  table  for  a  given  annllcation 
program  (or  run  unit)  identifies  the  record  occurrence  "most 
recently  accessed"  by  the  run  unit  for  each  of  trie 
following;  eacn  tyre  of  record,  each  tyoe  of  set,  "anv  tyoe" 
of  record,  and  each  tyoe  of  realm  C’ealm  is  a  COi'ASYb 
concept  that  win  not  he  considered  In  this  thesis,)  "Any 


type"  of  record  refers  to  the  most  recently  accessed  record 
occurrence ,  no  matter  what  Its  type  is.  This  record  is 
aoproprlately  called,  the  cu££fial  a£  ££a  £Ua  uoX£  ,  and  is 
the  most  imoortant  currency  of  all.  Additionally,  tne 
cu££fia£  o£  tba  set  tuae  n^ay  be  either  an  owner  record  or  a 
memoer  record,  whichever  was  accessed  most  recently, 

B,  l)ATA  structures  NECESSARY  FOR  ACCURATE  TWANSLATICU 

1.  Xbe  Cu££eacu  ladicatas  Zable  (CIXl 

A  currency  indicator  table  (CIT)  is  created  for  each 
application  orogratr.  that  is  run  using  the  dUC-S  network 
Interface,  These  tacles  are  dynamic  in  nature.  They  are 
instantiated  upon  the  first  call  to  the  dataoase  system,  ano 
are  updated  as  subseauent  CODASYL-DML  calls  are  made  to  the 
datacase  system, 

CTT 

m.iN_(iNiT 

record.type 

database.Key 

record.type ( 1 ) 
database. Xey 

set. typed) 

boolean  Cls  record  an  owner  record) 

record. type 

datapase.tcey 

member. record.tyne 

owner. record. type 

owner. dataoase. Key 

Figure  13:  information  Contained  in  the  CIT, 

The  CIT  contains  an  entry  for  the  current  of  run 
unit,  the  current  of  record. type  for  eacn  record.tyne  in  tne 


I 
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database,  and  the  current  of  set-type  for  each  set-type  In 
the  database.  Each  entry  In  the  CIT  should  contain  at  least 
the  Information  snown  In  Fioure  13  as  sugcrested  hy  Meyer 
['’ef.  133, 

2.  lb A  SAaUASl  aullAfi  (fi&) 

When  mapping  the  CODASYL-Oml  statements  to  awol 
requests,  there  are  one-to-many  correspondences  petween  tne 
two  types  of  statements.  Thus,  for  each  CODASftj-DML 
statement,  several  ABOL  requests  may  nave  to  oe  generated  to 
assemble  the  necessary  Information  for  accurate  execution  of 
the  translated  COi)ASYL-i)ML  statement.  In  otner  words,  a 
series  of  abdl  requests  may  be  aenerated  for  each  crdAoYL- 
OML  statement.  Some  of  tne  reouests  are  Initial iv 
Incomplete,  nowever,  and  require  Information  returned  oy 
previous  petrievk  reouests  which  are  a  part  of  that 
statement's  translation.  This  Implies  the  need  for  storaoe 
of  Intermediate  Information  tor  the  requests, 

rne  request  buffer  (RB)  acts  as  that  storaoe 
mechanism  tor  Information  returned  by  what  we  term, 
auxiliary  retrieve  requests  (ARR'S),  There  must  be  one  Rn 
for  each  RETRIEVE  request  Issued,  The  exact  role  that  each 
buffer  clays  is  explained  in  tne  next  section  of  this 
Chanter,  In  qeneral  though,  upon  successful  execution  of  an 
APR,  all  record  occurrences  satisfying  tne  request  are 
maintained  In  the  ouffer.  This  Information  is  then  used  for 
subsequent  request  execution. 
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C,  mapping  the  find  statements  to  the  abdl  retrieves 
The  general  format  of  the  cnoASTL  find  statement  Is 

FiNh  record.selectlon-exoresslon  [  ]  , 

while  the  general  format  of  the  A8DL  retrieve  is 

RETRIEVE  Query  Target-list  1  by  Attrloutes  3, 

As  previously  stated,  there  are  several  formats  for  the  FIND 
statement,  each  with  a  different  functionality.  Some  of 
these,  nowever,  are  thought  to  be  considerably  more  useful 
than  others,  so  we  only  concern  ourselves  with  the  ones  of 

most  value  In  the  mtiDS,  Before  proceeding,  tne  reader 

should  note  that  in  CODASYL  statements,  upoer-case  notation 
represents  literals,  lower-case  represents  user  supolled 
variable  names,  and  square  brac<ets  Indicate  optional 
clauses,  we  now  examine  tne  mapping  Process  for  each  of  tne 
CQdASYL  statements  to  be  Included  in  the  mods  networ< 
Interface, 

1,  l&a  CIliO  S£d£aBe&£ 

The  find  any  statement  tells  the  database  syste'^  to 
locate  any  record  of  type,  record^tyoel ,  whose  values  for 
Itemi  throuoh  itemn  match  those  In  tnat  record's  template  in 

the  user  worK  area.  The  syntax  for  the  FIND  any  Is: 

FIND  ANY  record«tyoel  USING  Iteml,  ,,,  , Itemn 
IN  record.typel , 

To  nerform  the  mapcing  of  this  statement,  the  Kernel  maoolng 


systeoi  (KMS)  must  first  substitute  tne  word  RETPIKVp;  for  the 
words  Fl’Jr  ANY,  Then  the  KMS  must  form  a  predicate,  fTYPE  = 
record-typel ) ,  for  Inclusion  In  the  final  query.  The  next 
step  In  tne  orocess  requires  the  kms  to  determine  tne  values 
that  the  search  Is  to  be  based  on.  These  values  are  found 
in  record.typel 's  record  template. 

After  acaulrlnq  these  values,  the  K»ts  then  forms 
additional  predicates  for  the  data  items  sneclfleci  In  the 
orldlnal  statement,  and  Includes  these  predicates  in  tne 
query.  Since  all  of  tne  necessary  Information  is  available 
to  the  KMS  for  this  particular  COOASYL  statement,  tnere  is 
no  need  for  an  auxllliary  retrieve  request  (ARR),  however, 
an  K6  Is  needed  to  store  the  retrieved  data  once  tne  request 
has  been  executed, 

with  tne  query  now  formed,  tne  kms  creates  a 
taraet-llst  to  complete  tne  RETRIEVE  request.  The  tanet- 
list  consists  of  all  attributes  of  the  requested  record. 
Thus,  tne  translated  COOASYL-Omi,  statement  Is: 

RETRIEVE  Cf  TYPE  =  record.tyoel )  and 
(Iteml  s  uscr«valuel)  and 

:  and 

(Itemn  =  user_va luen ) ) 

(  all  attributes  )  t  by  hBKEY  ). 

This  request  Is  then  oassed  to  tne  KC  of  the  int  rface  for 
execution.  An  examole  utillzlna  our  samole  database  will 
helD  to  Illustrate  the  mechanics  of  tne  mapolnq  process. 


The  requirement  Is  to  flni  any  Sucpiler  record,  s, 
where  that  suopXler's  city  is  'Cleveland',  The  CQhASVL 
procedure  Is: 


MOVE  'Cleveland'  TO  CITY  iv 
FIND  ft.VY  S  USING  CITY  IH  S 


(fJote:  The  '<OVE  statement  is  an  asslqnment  statement  found 
in  the  host  COBOL  lanauaqe,)  The  KmS  would  respond  to  tnis 
series  of  code  oy  performlno  the  followlno  actions; 


step  1;  'Cleveland'  is  placed  in  t!»e  S  template  for  the 
attripute  CITY, 

Step  7:  A  SETRIFVE  request  is  formed  as  such; 

RCT«IEVE  ((TYPE  s  S)  and 

(CITY  s  'Cleveland')) 

(SflQ,  SMAME,  STATUS,  CITY) 

Py  OBKEY 


Step  3;  The  KiYS  passes  the  request  to  the  KC  for 
execution. 

This  ooeratlon  results  in  havlno  all  s  records  satisfvlnq 
the  query  ( CTYPE  =  S)  and  (CITY  =  'Cleveland'))  Placed  in 
the  request  Puffer  and  sorted  according  to  tne  value  of  the 
database  >feys.  Figure  14  shows  tne  contents  of  5ufl  after 
t!ie  RET^iIFVE  is  executed. 


f  ....... .....................  4- 

I  t 

I  <S6, Mathews, 25, Cleveland>  | 

I  <SH , dopes , 30 ,Cleveland>  I 
I  I 


Fioure  14 !  Cop tents  of  oufl  After  RETRIEVE, 


Upon  Issuance  of  a  GET  statement  by  tbe  user,  tne  first 
record  In  tne  RB  is  returned,  provided  tne  RETHieVE  has  been 
successful, 

2.  iba  £1!:S  CUfiSeuz  Slataaa&t 

The  FIMD  CURRENT  statement  is  a  rather  slmnle  one  in 
that  no  direct  mapolnq  to  an  A»OL  request  Is  necessary. 
This  statement  Is  used  to  chanqe  the  current  ot  run  unit 
Indicator  from  its  present  value  to  the  value  of  the 
database  Kev  of  the  current  record  of  set.typel.  Tons,  the 
Interface  has  the  responsihllity  of  updatlnq  the  current  of 
run  unit  Indicator  (l,e,,  CtT,RUi!.UNiT, tyoe  <--  record. typel 
and  CIT,RU';.UNlT,dbkey  <-«  dokey  of  current  of  set-tyocl). 
The  syntax  for  this  statement  is: 

FIN'D  CiJftKe.MT  record. tyoel  rlThlN  set.typel 

As  an  example  of  this  process,  suppose  've  cieslre  to 
start  a  search  at  the  current  SP  occurrence  in  set.tyoe  S- 
SP,  The  COOA.'SYL  statement  would  be: 

FIND  CURHENT  SP  WITHIN  5-SP 

After  encounterlpq  tnis  statement,  the  k.vs  nesses  the  upoate 
Information  on  to  the  kc  for  execution,  Tne  SC  then  uodates 
the  currency  indicators  to  reflect  tne  cnanaes.  Trie  current 
of  run  unit  becomes  the  current  SP  record  occurrence  of  tne 
current  S-SP  set  occurrence. 


3.  Z&e  Sld2  Qli2LlC12K  HZIUZU  &t»tasua£, 

The  FIND  DUPLICATE  statement  Is  usei  for  sequential 
access  within  a  particular  set  occurrence.  It  locates  tne 
first  record. typel  record  within  tne  current  set.tynel 
occurrence  whose  values  for  Itemi  through  itemn  match  ttiose 
of  the  current  record  of  set.tyoel,  the  syntax  used  for 
this  statement  Is; 

FIND  DUPLICATE  WITHIN  set.typet  USING 
itemi,  ,ltemn  IN  record. tyoel 

The  maoolnq  process  for  this  request  assumes  that 
tne  records  being  requested  are  already  in  an  r«a. 
Therefore,  no  RETRIEVE  request  is  generated  for  tnis 
statement,  Insteaa,  tne  KhS  forwards  tne  set  type,  record 
type,  and  the  data  Item  n<3m«(s),  on  which  the  search  is 
based,  to  the  KC,  The  KC  then  taKes  ttils  information,  and 
locates  the  RB  contalnlnq  the  set.  It  then  compares  tne 
specified  data  item  values  for  the  current  recoro  of  tne  set 
type  to  each  of  the  other  member  records  until  the  first 
duoiicate  record  wltnln  tne  set  is  found.  This  record  is 
made  avallaole  for  return  to  the  user,  ine  CIT  is  then 
uooateo  to  reflect  the  new  currency  status.  This  approach 
is  advantaoeous ,  in  that,  ail  of  tne  records  for  a 
©articular  set  occurrence  are  already  avaiianie  in  an  Rb, 
ellmlnatlnq  tne  reed  for  further  accesses  to  the  database  in 
the  event  of  subsequent  requests  tor  duplicate  records,  such 
as  would  ue  tne  case  in  a  looo. 


The  followlnq  example  Illustrates  the  maopim 


process:  Find  the  next  shipment  record  tor  supoiler  SI  In 
which  the  quantity  snipped  Is  100,  A  possible  COhflSYL, 
procedure  for  accomplishing  this  consists  of  the  follov*ing 
statements : 


mSVE  'Si'  TU  SNO  lei  S 
FIND  AN?  S  IJSIfJG  SrO  IN  S 
'irjVF  too  TO  OTY  IN  SP 

find  SP  wdTHl.N  S-SP  CHRPfc.NT  USING  QTY  IM  SP 
FIMn  DUPLICATE  WITHIN  S-SP  USING  DIY  TN  SP 


The  effect  of  the  first  four  statements  is  to  locate  the 
first  S?  occurrence  for  supplier  Si  that  has  a  DTY  of  loo. 
The  next  statement  finds  the  next  SP  recora  in  the  S-SP  set 
with  the  same  aiY,  namely,  100, 

The  interface  would  rasnond  to  the  FIND  DUPLICATE 
request  as  follows: 


Step  t:  Execution  of  the  first  four  statements  produces 
the  results  In  the  «b  of  Figure  15, 


Step  2;  The  KC  then  gets  the  value  of  the  data  Item, 
QtY,  by  qoina  to  the  RP  and  finding  tne  current 
record  of  the  s-SP  set  using  the  record.tyoe  and 
set_tyoe  Information  given. 


Step  3;  The  KC  now  locates  the  next  record  In  the  s»*c  with 
CiTY  s  IOC  and  ma<es  It  ready  for  return  to  the 


I  I 
(  <S1,P5,100>  I 
I  <S1,P6,1C0>  I 
I  <Sl,P9,100>  I 
I  <S1,P10,100>  I 
i  I 

Figure  l5j  Contents  ot  bull, 

4.  Ibc  SXiiS  eia&I  sratciBa&£ 

The  FIND  FIRST  Statement  locates  the  first  me^nher 
record  of  a  set  occurrence.  This  statement  has  several 
other  forms:  find  LAST,  find  next,  and  FIND  PRIDR,  since 
they  are  all  mapoed  in  exactly  the  same  way,  we  only 
describe  the  maoPlm  orocess  for  the  FIN’D  FIRST,  The  syntax 
tor  the  FIND  FIRST  Is: 

FIND  FIRST  record.typei  within  set.tyoel 

Uoon  encountering  the  FIND  FIRST,  the  <mS  must 
ensure  that  record. tvrel  Is  a  member  record  tyoe  of 
set.tyPBl,  This  Is  necessary,  since  this  particular  find  Is 
based  on  the  currency  Indicators,  and  the  current  of 
set.typel  may  ne  an  owner  record,  us  noted  earlier  when 
dlscusslno  currency  of  set  types.  Assuming  that  the  current 
record  of  set.typel  Is  a  member  record,  tne  khs  then  forms  a 
HFIRIEVE  reauest  that  will  retrieve  every  member  record  of 
the  current  set.tyoel  occurrence  into  Its  ks,  rne  interface 
would  then  only  have  to  return  the  first  record  In  tne  set 
In  order  to  satisfy  the  request.  If  the  statement  had  been 


FI*'0  LAST 


the  last  record  In  the  set  would  be  returned 


The  resDonse  would  be  similar  for  the  FTNh  vext  and 
PRIQR  statements,  ftssumlnq  that  the  set  occurrence  has 
already  oeen  retrieved  Into  an  K3,  the  interface  would 
slTDiy  locate  the  current  record  of  set.tyoel  in  the  kh  and 
return  the  record  after  It  In  the  case  of  FIMD  ‘»EXT,  or  tne 
record  before.  It  in  the  case  of  tne  find  prior.  The  fact 
that  all  of  tne  member  recoras  of  tne  set  occurrence  are 
already  in  an  Ra,  eliminates  the  need  for  additional 
dataoase  accesses.  Thus,  the  only  AohL  request  that  need  pe 
formed  Is  this: 

retrieve  ((TYPE  =  recor d-typel )  and 

( UEMHER,  set-type  1  s  owner.dpicey.set'tyDet ) ) 

(all  attributes!  tby  DS^EY] 

fts  an  example,  consider  the  following  request;  Find 
all  the  Dart  numoers  iPNO's)  for  parts  supoiled  by  supolier 
S4,  A  oosslble  CODASYL  procedure  to  accomplish  this  would 
be : 

MOVE  'S4'  TO  SNO  IN  S 
FTMO  ANY  5  USING  SNO  TN  S 
MOVE  'NU'  T'  EOF 
FI. JO  first  SP  wITHlU  S-SP 
PERFORM  U'lTIL  EOF  =  'YF3' 

GET  SP 

(add  pun  IN  SP  to  r«»suit  list) 

FIND  NEXT  SP  WITHIN  u-SP 
END.FFRFOPM 

The  statements  of  concern  here  are  the  find  first 
and  the  FIND  NEXT,  the  reader  need  only  be  aware  tnat  in 
CCDASiL  only  one  record  at  a  time  Is  made  available  to  the 
user.  Thus,  the  need  for  tne  perform  loon. 


In  resDonse  to  the  above  sequence  o<  statements,  the 
Interface  would  perform  these  steps: 


Step  1;  The  K^s  of  the  Interface  would  form  a  RRmiEVE 
request  to  qet  all  members  of  the  S»S?  set  owned 
by  supplier  S4,  since  eacn  record  has  a  predicate 
Which  identifies  them  as  memoers  of  a  particular 
set  occurrence,  the  task  Is  fairly  easy.  The  re¬ 
quest  Is: 

RETRIEVE  ((TYPE  =  SP)  and 

(MEMt^ER.S-SP  s  dbkey  of  S4)) 

(SMO,?MO,OTV)  [by  PNG] . 


The  results  of  executlnn  this  request  are  shown  In  Floure 
16,  we  can  see  that  every  member  record  of  the  set  nas  been 
fetched  from  the  database  and  is  available  for  return  to  the 
user.  The  El'^D  FIRST  causes  the  first  record  to  be  returned 
to  tne  user, 

steo  2:  Jiince  the  cnoASYL  orocedure  nas  a  FivD  wext 
statement,  tne  same  RB  is  used.  In  other  words, 
the  KC  does  not  need  to  execute  a  new  retrieve  re¬ 
quest,  It  merely  makes  available  the  next  record 
in  the  RP  until  all  records  have  ceen  returned  to 
the  user  as  per  the  loop. 

Since  we  are  only  looking  for  Pdc  values,  the  interim  user 
code  would  specify  the  attribute  to  be  returned  and  tne 
interface  would  respond  accordlnaly. 


I  I 
I  <34,P2,200>  I 
)  <S4,P4,300>  I 
I  <S4,p4,4oq>  I 
I  I 

Figure  lb;  Contents  of  flufi  After  hETpIEve, 


5.  ztia  ez;i&  Skues  szazeseat 

The  FIND  owner  statement  causes  the  owner  of  the 
current  of  set.type  occurrence  to  be  returned  to  the  user. 
The  syntax  for  this  statement  is: 

FIND  OWNER  WITHIN  set.typel 

The  mapolnq  of  this  statement  is  relatively  strainhtforward. 
The  KMS  must  simply  form  a  PKTHIiVE  request  oaseo  on 
Information  available  in  the  CIT,  Tne  KAS  examines  the  OIT 
entry  for  set.typel  and  extracts  tne  owner's  type  and 
database  trey  value  directly  from  the  table.  It  is  then  an 
easy  tasx  to  form  the  request: 

RETRIEVE  ((TYRE  s  owner  Of  set-tYpeU  and 

(DRKEY  s  owner  dbkey  of  set,typel)i 
(all  attributes) 

As  an  example,  supoose  we  want  to  know  the  STATUS  of 
the  supplier  for  oart  numoer  P6«  Let  us  assume  that 
previous  statements  nave  set  up  the  current  S-5?  set 
occurrence  to  be  S2/P6/20,  The  CODASYL  statement  is; 

FIND  OWNER  WIThlM  S-SP, 

In  resDonse  to  tnls  request,  the  interface  takes  the 
followinq  action: 

Steo  1;  The  Kms  forms  the  request: 

RETRIEVE  ((TYPE  *  3)  and 

(D3KEY  s  dhxev  ot  32)) 

( SNO, SN A dE, STATUS, CITY) 


StCD  2:  Trie  kc  would  cause  tie  execution  of  the  above 
request,  resulting  In  an  RB  containing  one  recora, 
naiTiely,  the  S2  record. 

Based  on  the  Interim  user  code,  the  STATUS  value  Is  returned 
to  tne  user  from  the  RB  by  the  Interface, 

6,  Iba  £IUC  UIXUIU  CUfia£:t2  S£a£afiaQ& 

This  statement  causes  the  first  record  within  the 
current  occurrence  of  set«typei  whose  values  for  itenl 
through  Itemn  match  those  in  the  u&a£  ;iiacic  asaa  for 
record.tyoel ,  The  following  syntax  Is  used  for  this 
statement , 

Fli'jii  record.tyoel  wiTHth  set-tyoel  CURPP;>iT 
USINC;  Itemi,  ,,,  ,ltemn  rccord-typel 

This  statement  Is  similar  to  the  FTMu  nypLicATE 
exceot  that  the  search  values  are  obtained  from  the  user 
vice  the  current  record  of  set  tyoe.  Thus,  only  a  single 
RFfRirVE  request  Is  needed.  That  request  taxes  the  form! 

hfTRIKVE:  (CTPYF  *  record-typel )  and 

( ve MPEH , set.tvpel  =  dbxey  of  owner  set.tvoel) 
and  (Itetnl  =  user  vaiuel) 

and  ■ , , 

and  (Itemn  s  user  valuen)) 

(all  attrioutes)  (tv  Dpkey] 

This  request  Is  then  oassed  to  the  .<C  tor  execution,  if 
there  is  more  than  one  record  satisfying  this  query,  tne  wp 
for  me  reauest  contains  tnem  all,  however,  only  me  first 
record  encountered  Is  returned  to  the  user, 

to  Illustrate  the  process  of  this  maooinq,  we  return 
to  a  orevlous  example:  ktm)  the  first  shipment  for  supnlter 


SI  In  which  the  auantltv  Is  lOO,  Ustna  the  first  four 
state'^ents  from  the  exatiole  In  section  C,3  we  have, 

vovf..  SI  ro  SMO  3 
Finn  A'JY  s  usi-JG  SMO  in  s 
MOVE  100  TO  ^TY  IN  SP 
FIND  SP  within  S-SP 

CNRKENT  USING  QTY  IN  SP. 

In  orrier  to  carry  out  this  request,  the  followinq  steps  are 
taken  oy  the  Interface: 

Sten  l:  The  kms  forits  the  request: 

RETRIFVF  ((TYPE  =  SP) 

and  (’“'EMPER.S-SP  =  dhkey  of  SI) 
and  COTY  =  100)) 

(S''0,PN0,QTY)  [by  DuKEY) 

Steo  2:  The  kc  executes  the  above  request  and  causes  tne 
first  record  in  the  k3  to  oe  naqe  available  to  tne 
user , 

D.  CAPPING  THE  CODAoYL  GET  STATE^’FNTS 

The  GET  statements  in  the  COPASYL-D<'L  can  oe  considered 
as  data  retrieval  statements  iust  as  tne  FI JD  statements 
are,  except  that  tne  GET  request  can  only  access  records 
that  have  oeen  previously  identified  oy  a  Fl'io  statement. 
It  is  tne  statement  that  actually  gives  the  user  access  to 
the  individual  records.  There  are  three  options  available 
witn  the  GET  statement,  and  we  examine  eacn  in  turn.  In 
develoPino  tnese  maorlnas,  we  decided  not  to  directly  m^p 
the  GET  statements  to  AtuhL  RKTRiFyE's,  hut  to  slmoly  Issue 
instructions  to  the  KC  for  handllna  them. 
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1.  Z&e  SCI  aod  ubZ  ceca£d.£»Ba  dtataaeata 

The  GET  statement,  without  the  specltication  of  a 
particular  record  type,  causes  the  entire  current  record  of 
run  unit,  that  Is,  every  data  field  in  the  record,  to  oe 
returned  to  the  user  via  the  User  Wor<  Area  C'JwA),  In  tne 
MLOS  network  interface,  recoqnlton  of  this  statnent  hy  the 
KMS  results  In  the  followinq  response: 

Step  1:  The  Kws  Informs  the  kc  that  the  "next"  available 
record  in  the  ftB  that  contains  records  of 
the  tyoe  C^T,RU^«uvIT,tvDe  is  to  oe  oasserj  to  the 
user,  ^/ote  that  the  type  of  the  current  of  run 
unit  does  not  matter  in  this  case. 

The  GET  record. type  statement  is  identical  to  the 
GET  option  alone,  with  tne  exception  that  the  user  soeclfles 
a  Particular  record  tyoe.  In  this  case,  the  x^S  must 
determine  tt  the  tyres  of  the  current  of  run  unit  matches 
the  record  tyoe  specified  before  issulnd  instructions  to  the 
KC,  Also,  every  data  Item  is  returned  to  the  user, 

Returnina  to  our  examoie  In  section  C,4,  tne  "GET 
SP"  statement  causes  the  return  of  the  record,  <S4,P2,200>, 
to  the  user  the  first  time  the  GET  Is  issued  and  each  of  the 
other  records  In  sequence  as  the  loop  continues, 

2,  Zbfi  se:  itsal,  ,,,  flBaoa  Stataae&B 

Unlike  the  other  GET  options,  this  statement  causes 
specific  data  Items  to  be  returned  to  the  user,  Ihe  syntax 
of  the  statement  Is; 

GET  l»'eml,  ,,,  ,itemn  IN  record. tyoel , 


The  KM5  rnust  compare  the  record. type  to  the  current  of  run 


unit  and  also  ensure  that  the  data  items  listed  matcn  the 
data  Items  In  tne  record  tyoe  specified.  Once  this  Is  done 
and  is  successful,  the  KMS  Issues  instructions  to  the  KC 
just  as  in  the  above  case.  Only  this  time,  specific  data 
items  are  returned  from  the  records  accessed. 

As  an  example,  suppose  we  wanted  only  the  pNO  values 
from  the  SP  records.  The  value  returned  from  our  last 
example  would  be  P2,  with  subsequent  GST  statements 
returning  each  Pivcj  value  in  succession, 

E,  VAPPIMG  THE  DATA-lJPhATING  STATEMENTS 

In  this  section,  we  examine  the  CONNECT,  DISCONNECT, 
STORE,  MODIFY,  and  ERASE  Statements,  At  this  point,  the 
reader  Should  nave  a  basic  understandlno  of  the  maoDinq 
crocess  as  previously  described.  Thus,  for  the  sa<e  of 
orevity,  the  reader  is  referred  to  CRefs,  7,  9,  and  12]  for 
detailed  descriptions  of  the  statements  and  any  restrictions 
Involved  with  their  use.  We  therefore,  confine  our 
discussion  of  these  statements  to  a  broad  definition,  tne 
mapping  process  Itself,  and  In  most  cases,  an  example, 

1.  iba  ca:i:;£Cl 

The  CON^'FCT  statement  is  used  for  manual  Insertion 
of  the  current  record  of  run  unit  into  the  current 
occurrences  of  the  set  typeCs)  specified.  The  syntax  is: 

connect  record.tvnel  TO  set.typel,  ,,,  .set.tvoen. 
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This  statement  requires  that  the  record-tvpel  record  be  a 
member  of  the  sets  specified  and  also  have  an  insertion 
clause  of  MANUAL  for  those  sets. 

The  CONi'iECT  statement  maps  directly  to  the  ABDL 
UPDATE  request.  The  UPDATE  format  is: 

UPDATE  Query  Modifier 

In  the  case  of  the  CQmnpct,  the  mapping  is  very  simple. 
First,  the  KMS  replaces  COMueCT  ny  tne  «ora  updatf.  Then, 
the  type  and  database  tcey  of  tne  record  to  oe  inserted  is 
taken  from  the  CIT  to  form  the  query  cfTYPF  =  record. tyoel ) 
and  COBKEY  s  CIT,RUM.UMIT.dbkeY)),  Finally,  in  order  to 
construct  the  modifier,  the  XMS  get  tne  database  key  of  the 
o<»ner  of  the  current  occurrence  set.typel  from  tne  CIT,  The 
K'^S  then  forms  the  modifier,  f  member,  set.tyrei  s 
CIT, set.typel, owner-dbkey)  for  each  set  type  specified. 
Each  sat  type  specified  has  its  oen  complete  update  request 
generated , 

Hne  fflldht  ask,  'ihy  use  an  UphATE  instead  of  an 
IMSERT  request,  **ell,  tne  difference  is  that  the  COumect 
statement  Involves  records  already  in  the  dataoase.  And, 
because  the  <ev'*ord,  <f>FMfa£F, set. type, Is  in  the 
record  »»hese  connection  value  is  null,  it  oecomes  a  slmnie 
matter  to  just  update  that  Particular  keyword,  thereby 
connecting  the  record,  we  recall  that  in  an  attribute-based 
database,  keywords,  not  pointers,  are  used  to  connect  one 
record  to  anotner.  The  INSERT  statement  on  tne  otner  nano. 


involves  records  nor.  already  in  the  database.  Thus,  the 
completely  translated  CTNMECT  state'^ent  is; 

UPDATE  ((TYPE  a  record. typel)  and 

CDBKEY  a  CIT, RUN.U'ilT, dbtcey ) ) 

(MEMBER, set. typei  a  Cir, set. typel, owner. dbkey) 

2,  l&A  012CQUa[£CZ  Stateaacit 

The  DISCONNECT  is  just  the  opposite  of  the  connect 
statement.  It  causes  the  current  record  of  the  run  unit  to 
be  disconnected  from  the  set  listed.  The  set  occurrences 
selected  are  determined  by  the  current  of  set  type 
Indicators,  Since  several  set  types  may  be  listed  in  tne 
statement,  only  one  statement  is  needeo  in  order  to  maice 
several  removals.  The  records  still  remain  In  the  database. 
They  are  slmbly  disconnected  from  soeciflc  sets.  The  syntax 
is : 

DISCONNECT  record.tvpel  FRUM 
set.typel,  ,,,  ,set.typen. 

The  DISCONNECT  Statement  renulres  that  record. tynel 
be  a  member  of  tne  set  types  listed ,  and  tnat  the  record  be 
removed  from  the  set  occurrences  that  are  current,  Because 


of  the 

way 

we 

represent  set 

mempershiD  In 

tne  attrloute- 

based  record. 

tnls 

tas<  is  verv 

simple. 

Since  we 

are 

disconnecting 

the 

current  of 

run 

unit 

,  and 

it  contains 

tne 

database 

leeys 

of 

the  owners 

of 

tne 

set 

occurrences 

it 

belongs 

to, 

and 

since  eacn 

record 

can 

only  ne  in 

one 

occurrence  of  the  sam?  set  type  (oalrwise  disjointness),  tne 


mapDing  process  Is  direct,  we  sli^oly  £or*n  an  UPDflTF  request 
for  each  set  tyoe  listed.  Thus,  the  iceyword, 
<Mt:!^0F:R,set.tYpel,owner«dbl<ey>,  Is  ’nodiflea,  and  beco'f'es  the 
Keyword,  <ME:M0ER,set-tYpel,fiULL>,  To  accomollsh  this,  tne 
K-1S  forms  tne  reouest, 

UPDATE  ((TYPE  =  record.tyoel )  and 

(DnKEY  s  CTT,R'JV.l>r4lT,dbKev) ) 

(MEMBER. set-tynei  =  uur.L) 

and  passes  it  to  the  KC  for  execution, 

3.  Ibc  4aQi£;:(  Statefiaat 

The  '100IFY  statement  causes  the  entire  current 
record  of  tne  run  unit  to  be  modified  or  specific  data  Items 
In  that  record  to  ee  modified.  The  syntax  Is  either, 

MODIFY  record.tyoel ,  or 
MODIFY  itemi,  ,,,  ,ltefnn  lu  record-type  1 , 

This  statement  also,  has  a  rather  straightforward 
mappina  to  the  AriOL  UPDATE  request.  The  statement  assumes 
that  tne  user  has  supplied  the  necessary  aaca  Item  values 
for  modification  In  record-tynel 's  record  template  In  the 
UkA,  Therefore,  the  job  of  the  kms  portion  of  tne  interface 
Is  to  get  this  user  supplied  Information  ang  form  tne 
following  UPDATE  request  for  each  data  Item  to  he  modified; 

UPDATE  ((TYPE  s  r ecord-tvne I )  and 

(DhKEY  a  Cl T . RUr'.UN  1 T, dbKev)  ) 

(data  Iteml  a  user  value  for  1), 

As  an  example  of  this  process,  consider  changing  tne  STATUS 


and  CITY  attributes  of  supplier  S4  from  20  and  'London'  to 
15  and  'Cblcaqo',  resoectlvely ,  The  CODASYL  request  Is; 

MOVE  S4  TO  SNQ  IN  S 
MOVE  15  TO  STATUS  IN  S 
MOVE  'Chlcaqo'  TO  CITY  IN  S 
FIND  AMY  S  USING  SNQ  IN  S 
MODIFY  STATUS, CITY  IN  S, 

('»ote;  The  SNO  numbers  in  this  example  are  unique,)  Once 
aqaln  the  move  statements  set  up  tne  S  record  template  for 
use  by  holdlnq  the  new  values  for  the  S4  record.  The  kind 
statement  establishes  tne  S4  record  as  tne  current  record  of 
the  run  unit.  The  KMS  then  responds  to  the  MODIFY  statement 
by  formlnq  the  followlnq  two  UPDATE  requests  and  passlno 
them  to  tne  KC  for  execution, 

UPDATE  ((TYPE  a  S)  and 

(CftKEY  a  dbicev  of  S4)) 

(STATUS  a  15) 

update  ((TYPE  a  s)  and 

(DBKEY  a  dbicev  Of  S4)) 

(CITY  a  'Chicago') 

If  the  entire  record  was  to  be  changed,  the  first  ontlon 
would  have  been  used,  reauirlm  tne  KMS  to  form  an  t/PDAfF 
request  tor  each  data  item  in  the  S  record  type, 

4,  i;ia  SZCfiL  szateaeazs 

The  STORE  statement  is  used  in  the  CODASYL-dml  to 
Insert  a  new  record  into  the  database,  before  a  new  record 
can  be  Inserted  though,  it  must  be  constructed,  mis  taxes 
Place  in  the  UWA,  The  syntax  for  the  sThrt  is; 

SIORF  record.tvrel 


In  mapplnq  the  STORE  statement,  care  must  be 

exercised  In  determlninq  the  prooer  set  occurrence  in  wnlch 
to  place  a  record,  if  it  is  a  member  record,  Tnis  is 
necessary  only  in  the  case  of  automatic  insertion.  The 
interface  must  have  access  to  tne  original  database 

descrlDtion  in  order  to  determine  the  set  selection 

criterion  for  each  new  record  to  be  inserted.  The  three 
criterion  are:  by  APPLlCATTo-'i,  by  STRuClUH AL,  and  by  VAuut:, 
Each  of  these  requires  a  sliqhtly  different  mapoing. 

Therefore,  we  examine  each  individually. 

In  addition  to  the  set  selection  criterion,  the 
interface  must  determine  if  any  data  items  of  the  record 
being  Inserted  has  a  DUPLICATES  NOT  ALlowEL  clause  asslqned 
to  it.  In  tne  case  tnat  such  data  items  exist,  the 
Interface  must  form  a  RETRIEVE  request  to  determine  the 
existence  of  recoras  in  the  database  that  may  already  nave 
items  wltn  tne  same  value  as  those  in  the  record  that  is 
about  to  be  stored.  Thus,  each  STORE  statement  consists  of 
at  least  ore  ABDL  RETRIEVE  and  one  ApDl  INSERT  request,  we 
shall  see,  nowever,  that  additional  RETRIEVE'S  are  necessary 
tor  the  set  selection  criterion  of  SlRUCTURAb  and  value, 
a.  The  STORE-oy-Arnilcatlon  Statement 

This  method  of  set  selection  assumes  that  the 
or oner  occurrences  of  sets  are  indicated  in  the  CIT, 
Therefore,  the  Kf*s  forms  two  renuesrs,  tne  RETRIEVE  to 


deter-nlne  tne  status  of  duplicates,  and  the  INSERT  request 

which  stores  the  record.  The  process  is  as  follows: 

Step  1;  The  kms  for'^s  the  RETRIEVE  below  with  the  search 
based  OP  all  data  items  desionated  to  nave 
DUPLICATES  NDT  ALLOWED,  The  values  for  these  items 
In  the  new  record  are  supplied  by  the  user  via 
the  UwA  record  template, 

RETRIEVE! (TYPE  a  record. type  1 )  and 

(data  Iteml  s  user  valuel)) 

(OHKEY)  (by  OdKEY] 

Step  2:  The  kms  forms  the  I'^SERT  request 

I‘'SERT(<TyPE,record_tVPel>,<DdKEl 
<data  iteml, user  valuel>, 

<v-EH  BER,set-typel, set. typei, owner -dtkev>5 

and  forwards  both  requests  to  the  KC  for  execution. 

Step  3:  The  KC  Issues  the  RETRIEVE  request,  Tf  tne  sp 
returns  witn  no  D»KEYs,  then  the  insert  request  is 
executed,  Gtherwlse,  the  INSERT  is  not  executed 
and  an  error  condition  exists. 


D,  The  sroRE-by-value  statement 

The  by»VALUE  set  selection  criterion  means  that 
the  set  occurrence  we  need  has  a  aata  Item  whose  value  Is 
equal  to  the  value  in  the  soecifled  UwA  record  temniate 
which  has  that  data  item  as  one  of  Its  fields,  me  reader 
Is  referred  to  Flqure  lO  for  the  syntax  of  the  set  selection 
clause  of  sets  5"SP  and  P-SP,  as  examples.  This  type  of 
oTHRE  requires  that  the  data  ifem  in  question  have  a 
DUPLICAIES  NOT  ALLOWED  Clause  also,  and  that  the  user 
Initialize  the  data  item  in  its  uwA  record  temoiate  oefore 
Issuipq  the  STORE  request. 

The  by-var,iiE  criterion  tqerefore,  niaces  the 
additional  requirement  on  the  Interface  of  locatlna  tne 


owner  of  the  proper  set  occurrence  before  the  new  recori  can 
be  inserted  Into  the  database,  tms  is  accomplished  by  the 
Issuance  of  a  second  retrieve  reouest  by  tne  kc_  if  tne  first 
RETRIEVE,  as  mentioned  above,  returns  MULL,  The  steos  in 
the  process  are; 


Steo  1;  The  KHS  forms  the  first  RETRIEVE  as  above.  Then 
for  each  set  type  In  wnlch  the  new  record  is  a 
member,  a  RETRIEVE  request  is  formed  to  net  tne 
owner  database  key.  The  request  IS! 

PETRIEVEC (TYPE  =  owner  tvoe)  and 

(search  item  s  user  value)) 

(LMIKEY)  Cby  03KEY)  , 

Steo  2:  The  forms  the  followinq  INSERT  request: 

I%S£RT(<TYPc, record«typel>, 

<DnKEy, »*♦>, 

<data  ltemi,user  valuel>, 
kf'.  ember  ,  set-typel  ,»»»>) 


Steo  3:  The  kc  executes  the  first  RETRIEVE  to  oetermine  If 
duplicates  exist.  If  not,  tne  reralnlnq  RETRIEVES 
are  executed  in  turn  to  qet  the  database  keys  of 
the  owoers  of  the  set.  occurrences  to  wnich  tne  new 
record  belonos.  Once  tnese  values  are  returned, 
the  KC  finishes  building  the  INSERT  request,  and 
executes  it. 

c,  Che  STQRE-bv-Structure  Statement 

The  by-STRUCTUR'lL  set  selection  criterion  is 
similar  to  by**VALUE  except  that  the  prober  set  occurrence  is 
selected  by  comoarinq  a  data  Item  value  in  one  record  tyoe 
to  the  value  of  that  same  data  Item  in  anotner  record  type. 
From  our  samole  database,  we  could  nave  a  by-STRUCTUR Ah 
clause  Indlcatlnq  that  the  SmO  value  in  3  must  equal  tne  SmU 
value  in  sn.  Thus,  we  must  searcn  for  an  SP  record 


occurrence  «rlth  the  same  SNO  value  as  that  in  the  S  temolate 


In  the  UrtA,  Once  again,  this  data  Item  must  have  a 
DUPLICATES  UOT  ALLOWED  specification. 

The  mapplno  here  Is  Identical  to  that  for  the 
by-VAf.UE  case  except  tnat  the  second  through  ith  retrieves 
are  cased  on  equality  of  values  In  senerate  records,  since 
the  Idea  Is  the  same,  we  will  not  give  the  specifics  of  the 
mapoinq  here.  It  Is  Presented  In  detail  In  the  Appendix, 

5.  Ibe  ££&££  Sta&eBfia£& 

The  ERASE  Is  the  final  cnuAsYL-DwL  statement  we 
consider  for  the  mlds  network  Interface,  As  Implied,  It  is 
the  statement  that  causes  deletion  of  records  from  the 
database.  There  are  two  options  with  this  statement,  as 
oreviouslv  discussed  In  Chapter  2,  we  beoin  with  the  slmoie 
ERASE,  The  syntax  for  this  ERASE  statement  Is: 

ERASE  record.tyoei 

The  ERASE  without  the  ALL  ootioh  deletes  one  record 
from  the  database,  namely,  the  current  record  of  the  run 
unit,  Tne  only  reoulrement  Is  that  the  record  Is  not  tne 
owner  of  a  non-ert'Pty  set.  This  means  that  In  mapping  this 
statement,  we  need  to  Issue  a  RETRIEVE  renuest  orlor  to  the 
deletion  request  to  determine  if  there  are  any  sets  whose 
memoers  are  connected  to  this  record.  Therefore,  for  each 
set  tyoe  In  whlcn  the  current  of  run  unit  is  an  owner,  we 
have  a  predicate  In  the  RETRIEVE  query  of  the  form: 
(  dEi'-BER ,  Sftt.typel  s  Cl  T,  Rud^JwTT.abXey ) ,  The  request  Is: 

•j3 
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RETRIEVEC  (MEMBER, set-tyoel  s  CIT, PUM.i-'N I T. dbicey ) and 

•  and 

(MEMBER, set.typen  =  CIT.RUN-UNTT.dbkrey) ) 

(DBKEY)  (by  DBKEYJ. 

The  next  step  In  the  mapping  Process  Is  to  form  a 
DELETE  request  that  deletes  the  current  of  run  unit.  That 
request  is: 

DEL£TE((TYPE  =  CIT , R UH.UN IT, ty pe )  and 
(DOKEY  =  CIT,RtJ\'.U.'^IT,dbi<ey) ) , 

So,  the  KMs  in  this  case  issues  t.vo  abdl  requests  to  the  kc 
for  execution.  The  KC  -uould  execute  tne  retrieve  first.  If 
it  results  in  a  wULL  R6,  then  the  TELETe  Is  executed. 
Otherwise,  tne  ERASE  falls. 

The  second  ERASE  under  consideration  is  the  erase 
with  the  ALL  option.  The  ERASE  ALL  syntax  Is: 

ERASE  ALL  record»tyoel , 

As  mentioned  in  cnapter  2,  this  ootlon  is  llxe  a  "vacuum 
cleaner"  in  that  it  deletes  every  record  in  the  hierarchy 
startlnq  with  the  current  record  ot  t/)e  run  unit,  Tne 
oifference  oet*een  the  mapolnq  ot  this  statement  and  the 
previous  ERASE  is  that,  RETRIEVES  must  he  formed  to  get  tne 
database  xeys  of  each  member  of  every  set  that  the  current 
cf  run  unit  owns,  and  then  RETRIEVES  are  formed  recursively 
thereafter  for  the  members  of  lower  level  sets  until  the 


leaves  of  the  hierarchy  are  reached,  in  addition  to  these 
RETRIEVE  requests,  a  DELETE  request  Is  needed  for  each 
memoer  of  every  set  connected  to  the  current  of  run  unit  and 
the  current  of  run  unit  Itself,  As  one  can  see,  this  could 
become  quite  complex.  Therefore,  we  briefly  decrihe  the 
aloor Ithm,  and  refer  tne  reader  to  the  Appendix  for  tne 
details , 

In  mappinq  the  ERASE  ALL,  the  K^S  forms  a  RETRIEVE 
request  to  qet  each  memoer  of  every  set  owned  by  the  current 
of  run  unit.  It  then  forms  a  DELETE  for  each  of  these 
members.  Cnee  it  nas  taken  care  of  the  first  level,  the  k,ViS 
oroceeds  to  form  requests  .«hlch  erase  all  of  the  descendents 
In  tne  same  fashion  by  caiilnq  a  recursive  procedure  called 
"erase.aii".  Finally,  the  K?1S  forms  a  DELETE  request  to 
delete  the  current  record  of  the  run  unit  as  in  the  orevious 
ERASE,  This  concludes  the  desclptlons  of  tne  maoplna 
process  from  COhASYL-n^L  to  abdl. 


V.  lbSLStt£UZ&IXCtt  CQLSIDE&AZiauS 

In  Chapter  1,  we  provide  a  brief  description  of  the  four 
modules  Included  In  the  COOASYL  language  Interface,  namely, 
the  lamuage  Interface  layer  (LID,  the  kernel  nanolna 
system  (K'^S),  tne  icernel  controller  (kC),  and  the  <ernel 
formatting  system  (KF3),  In  this  chapter,  we  present 
considerations  for  the  Imoiementatlon  of  tne  kms  and  tne  kc, 

A,  rUF  KFRfJFL  MAPPI\f:  SYSTEM  (KMS) 

The  K'^s  is  the  second  mooule  In  the  ‘‘LOS  CDDASTL 
Interface,  It  is  called  fron  the  language  Interface  laver 
(LID  when  the  LIL  receives  CQOASYL  Input  requests  from  the 
user,  (n  this  section,  we  discuss  the  soeclf Icatlon  of  the 
K''S  (see  Anoenfiix)  for  the  network  (COdASVD  Interface,  we 
describe  Its  operation,  oresent  a  concentual  view  of  its 
data  structures,  and  oive  an  example  of  tne  kms  translation 
crocess.  Implementations  of  the  Khs  for  the  DL/I  and  30tL 
interfaces  can  be  found  in  [>^et,  “jcop,  4S»90)  and  Cf-ef, 
6:pr,  47-63],  respectively.  These  implementations  rrovi-ied 
Che  basic  framework  for  the  aeslan  of  the  CODASYL 

The  KM3  must  perform  the  tollowlno  functions:  (i)  aarse 
the  request  to  validate  the  user's  rohASYL  syntax,  and  (2) 
translate,  or  map,  tlie  request  to  equlvaiettt  AODL  reouests. 
Cnee  the  necessary  Appt,  requests  have  been  formed,  tney  are 
made  available  to  the  Kernel  controller  (f^C)  for  execution. 


1.  Iba  iiis  Ca£&fic/lca&slalfi£ 

The  grammar-driven  parser  Is  the  most  tmoortant 
aspect  of  the  kms.  The  Yet-Another-Comoiier  Compiler  (YACC) 
[Ref,  14]  Is  an  Ideal  choice  for  the  construction  of  the 
parser.  YACC  Is  a  prooram  generator  designed  for  syntactic 
processing  of  token  streams,  YACC  functions  as  folio «’s:  It 
must  he  given  a  specification  of  the  Inout  language 
structure  (a  set  of  grammar  rules),  the  code  tnat  is  to  be 
invoked  when  the  grammar  rules  are  recognized,  and  a  low- 
level  Input  routine  that  generates  tokens  from  a  regular 
expression  Input,  Given  these  Inputs,  YACC  generates  a 
program  that  syntactically  recognizes  the  input  language, 
and  causes  soeclfic  user  code  to  be  Invoked,  as  required, 
throughout  the  recognlton  process.  The  user's  code  here  is 
the  code  that  oerforms  the  CODASYL-Owu  to  Adnu  translation. 
The  Lexical  Analyzer  Generator  (LRX)  tRef.  15]  is  the  low- 
level  Incut  routine  that  we  orooose,  LCX  is  a  orogram 
oenwrator  designed  for  lexical  processing  of  incut  character 
streams.  It  takes  regular  expressions  as  input,  and 
generates  a  orooram  that  partitions  the  inout  stream  into 
tokens.  These  tokens  are  then  outout  to  the  parser  for 
further  processing. 

The  parser  produced  by  YACC  consists  of  a  finite- 
state  automaton  with  a  stack.  It  performs  a  too-down  parse, 
with  left-to-rloht  scan  and  one  token  look-ahead.  Control 
flow  within  the  parser  begins  at  tne  hianest-level  grammar 
rule,  Tt  then  descends  througn  the  grammar,  nlerarchlcally, 
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calllno  lower-  and  lower-level  grammar  rules  wnicn  search 


for  the  appropriate  tokens  In  the  Input  streams.  As  these 
tokens  are  recognized,  some  portions  of  tne 
mapplno/translatlon  code  may  be  Invoiced  directly,  Tn  other 
cases,  these  tokens  are  propagated  oack  up  the  grammar 
hierarchy  until  a  higher-level  grammar  rule  Is  satisfied. 
Once  a  rule  is  satisfied,  further  translation  can  be 
accomplished.  When  all  of  the  necessary  low-ievel  grammar 
rules  have  been  satisfied,  and  control  has  propagated  bacic 
UP  to  the  hignest-level  rule,  tne  oarsing  ana  maoping 
process  is  complete.  In  section  B,  we  provide  an  example  of 
the  parsing  and  translation  process, 

2,  iba  H'ASk  data  atsuctusaa 

The  KMS  needs  several  different  data  structures. 
However,  we  confine  our  discussion  nere  to  the  structures 
whlcn  carry  tne  Information  necessary  for  the  proper 
execution  of  the  translated  requests.  The  structures  that 
tall  Into  tnis  category,  are  the  CIT  structure,  and  the 
request  nodes  which  are  passed  to  the  kC  for  execution,  A 
description  of  the  minimum  requirements  tor  these  structures 
is  given  below. 

The  CIT  is  described  in  Chapter  4,  This  structure 
carries  all  of  the  currency  Information  for  a  oartlcular  run 
unit,  and  is  vital  to  tne  proper  translation  and  execution 
Of  COhASTh  statements.  The  Lil,  of  tne  interface  initializes 
the  CIT,  The  KMS  has  read  access  to  the  Cl f  at  all  times, 
While  all  updates  of  the  CIT  are  done  by  the  KC  only.  In 


the  following  sections,  we  discuss  each  of  the  data 
structures  that  are  directly  related  to  tne  parslno  ano 
translation  process, 

a.  The  'find^node'  Data  Structure 

The  £lnd«node  Is  created  and  used  any  time  that 
a  CODASYL  FIND  statepent  Is  mapped  by  the  K^S,  Since  we  are 
considering  the  Implementation  of  six  different  FIND 
formats,  we  must  ensure  that  the  flnd.node  has  at  least  four 
fields,  one  identifying  the  node  as  a  tind^node,  a  second, 
specifying  the  type  of  FIND  statement  that  must  be  executed, 
l.e,,  FIND  ANY,  FIND  CUHRENT,  FIND  OwNeP,  ana  FIND  wIThIN, 
one  field  to  Indicate  the  set  type  involvea,  and  one  field 
to  identify  the  record  type  used  in  the  statement, 

flnd.node 

+mmmmmmmmmmmmmm»mmmmmmmmmmmmm^ 

I  FIND  I 
I  type  of  FIND  I 
I  set  type  I 
I  record  type  I 


I  pointer  to  aadl  reauestCs)  i 
“■igure  17;  The  'flnd.node'  Data  Structure, 

In  addition  to  the  above  information,  each 
find. node  must  also  have  a  field  which  contains  a  pointer  to 
the  Specific  ABDL  request  that  resulted  from  the  maoplno 
process,  with  regard  to  the  FIND  CufkSNT  request  and  the 
FIND  DUPLICATE  reuuest,  no  AdOL  request  is  generated. 


Therefore,  the  pointer  would  be  wuLL,  Pliure  17  above 
Illustrates  the  type  of  structure  described,  where  the  dots 
represent  any  additional  Implementatlon-deoenaent 
inf orifatlon  which  might  need  to  be  included, 
b.  The  'get.node'  Data  Structure 

The  get  node  carries  the  information  that  the  KC 
needs  in  order  to  return  the  proper  data  to  the  user.  It 
must  have  a  field  identifying  it  as  a  get  node  and  a  field 

identifying  the  type  of  (JET  format  being  used, 

Aaditionally ,  a  field  identifying  tne  record  type  In 

question  must  also  be  included.  In  tne  case  of  the  GET 

Item.iist  format,  the  node  should  Include  a  pointer  to  a 
list  of  data  item  values  to  be  returned.  If  the  format  is 
(JET  record.tyoe,  the  pointer  field  would  be  NULt,,  and  tne  KC 
would  return  all  attributes  of  the  record.  The  same  is  true 
for  the  slmole  (JET  format,  Figure  ih  is  an  example  of  this 
type  of  structure, 

get_node 

I  CET  I 

I  type  of  GET  I 

)  record  type  I 


I  pointer  to  list  of  data  I 
I  Items  to  be  returned  I 

Figure  le:  The  'get_node'  Data  structure. 


c.  The  'connect.node'  Data  Structure 

The  connect.node  Is  created  ana  used  'Whenever  a 
CONNECT  statement  Is  mapoed  by  the  KhS,  .There  are  two 
orlmary  fields  In  this  node.  The  first  field  identifies  the 
node  as  a  connect. node.  The  second  field  Is  a  pointer  to 
the  list  of  AaOL  UPDATE  requests  generated  by  the  KMS  durim 
Its  orammar-dr iven  parse.  This  list  may  contain  one  or  more 
requests  deoendlnq  upon  the  number  of  sets  that  the  recoro 
must  be  connected  to,  as  described  in  Chapter  4,  Under  the 
current  implementation  of  the  wbds,  a  separate  update 
request  must  ne  executed  for  each  attribute  In  a  record  that 
Is  to  be  chanqeo.  Thus,  the  need  for  multiple  update 
requests.  Recall,  that  the  attribute  to  be  changed  in  this 
case  is  the  '<Er<BEK, set. type  attribute,  Figure  19  shows  the 
basic  structure  for  this  node, 

connect. node 

^.mmmmmmmmmmmmmmmmmmmmmmmmmmmmm  + 

I  connect  I 


I  Dolnter  to  list  of  UPDATE  I 
I  requests  I 

Elgure  lu;  The  'connect. node '  Data  Structure, 

d.  The  'disconnect. node'  Data  Structure 

The  dlsconnect.node  Is  created  and  used  whenever 
a  DISCONNECT  statement  Is  encountered  by  the  K^s,  Tne 
tleids  of  tnis  none  are  exactly  the  same  as  those  of  the 


connect. node.  In  this  case  however,  the  value  of  the 
attribute  member, set. tyoe  is  set  to  fJUUL,  dlsconnectlno  the 
record  from  designated  set  occurrences,  Once  again,  we  nave 
an  identifier  field,  and  a  list  of  UPDATE  requests, 

e.  The  'modify. node'  Data  Structure 

AS  with  the  dlsconnect-node ,  the  modify. node  is 
also  very  similar  to  the  connect. node.  It  Is  created 
whenever  a  mquify  statement  Is  encountered  by  the  KMs,  It 
nas  two  fields,  an  identifier  field,  and  a  oolnter  to  a  list 
cf  UPDATE  reduests,  Tne  update  requests  In  the  modify. node 
are  used  to  alter  the  value  of  specific  data  lta&  attributes 
within  a  oartlcular  record.  The  number  of  requests  on  this 
list  can  vary  from  one  to  the  maximum  number  of  data  Items 
In  the  record,  deoendlnq  on  the  modify  format  chosen  by  the 
user , 

f.  The  'store. node'  Data  Structure 

The  store. node  Is  the  most  interestlno  of  the 
data  structures  presented  so  far,  it  must  contain  at  least 
four  fields.  The  first  Is  tne  Identifier  tielo.  The  second 
field  Is  a  pointer  to  a  RETRIEVE  reauest.  This  request  Is 
oenerated  hy  the  In  order  to  determine  the  existence  of 
aupllcate  values  for  data  items  declared  to  nave  DUPF.icatf.s 
f.OT  ADLOeED  In  the  database  senema.  The  third  field  of 
importance  relates  to  tne  set  selection  criterion  for  tne 
record  being  stored.  It  Is  qenerated  to  retrieve  the  owner 


database  Kev(s)  of  the  oroper  set  occur rence ( s )  for  tne  new 


record.  This  request  is  only  generated  In  the  cases  of  the 
by-VALUE  and  by-STRiiCTUR AL  set  selection  crlterions, 

store. node 

I  sroRfi  I 

I  Dolnter  to  duplicate  RETRIEVE  request  I 

I  pointer  to  list  of  set  select  RETRIEVE  | 

i  requests  I 

I  •  I 

I  •  I 

I  •  I 

I  I 

I  pointer  to  INSERT  request  I 

i.mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm^ 

Figure  20;  The  'store. nooe'  Data  Structure, 

The  final  field  required  for  tne  store. node  is  a 
pointer  to  the  INSERT  request  #nich  will  actually  cause  tne 
record  to  oe  placed  into  the  database,  Figure  20  aoove  is 
an  Illustration  of  this  data  structure.  As  rentloned 
before,  the  dots  in  the  figure  represent  additional 
liTiolementatlon-decendent  information.  Should  the  set 
selection  criterion  be  by  APPLICATXOW,  tne  second  RETRIEVE 
pointer  would  be  NULL, 

g.  The  'erase. node'  Data  Structure 

The  final  data  structure  we  discuss  Is  the 
erase. node.  This  node  is  created  whenever  an  ERASE 
statement  is  mapped  by  the  KMS,  It  the  EnASE  without  the 
ALL  option  is  mapped,  the  erase. node  must  contain  tne 
following  four  fields.  First,  it  must  contain  an  identifier 
field.  Second,  it  must  contain  a  type  field  with  a  value  of 
iDiiL,  indlcatlno  that  It  does  not  nave  tne  ALI.  option.  The 


third  field  in  this  node  must  be  a  oointer  to  the  bftoievp 
reanest  that  will  determine  If  the  recora  beini  deleted  owns 
a  non-emoty  set.  Should  this  request  return  NULL,  tne  KC 
would  execute  the  request  stored  in  the  fourth  field,  Ihis 
is  the  field  containlnq  a  pointer  to  tne  DtLtTt;  request  that 
will  delete  tne  current  record  of  the  run  unit.  Figure  21 
qlves  a  representation  of  tnls  structure, 

er ase.node 

I  EKASb.  I 
I  type  of  E3ASE  I 
I  pointer  to  SETPIEVE  request  I 
I  •  I 
f  •  I 
I  •  I 
I  I 
I  pointer  to  run.unlt  DELETE  i 

Figure  2lJ  The  'erase.node'  without  the  ALL  OotJen, 

The  erase.node  created  for  tne  erase  aita  the 
ALL  option  will  be  considerably  more  complex  than  tne 
previous  case.  First,  there  must  be  an  identifier  field  and 
a  tyoe  field.  Then  there  must  be  t>o  pointer  fields,  Tne 
first  oolnter  field  will  point  to  tne  list  of  RETRIEVE 
requests  generateo  to  get  all  the  descendants  of  the  record 
being  deleted.  The  second  pointer  field  will  point  to  the 
list  of  DELETE  requests  qenerated  for  eacn  of  the  descendant 
records,  Finallv,  the  last  field  In  tne  structure  should  oe 
a  pointer  to  the  DELETE  request  that  deletes  tne  current 
record  ot  the  run  unit,  Flaure  22  is  an  example  of  this 


structure 


erase.node 

I  ERASE  I 

I  tyoe  of  ERASE  CALL)  I 

I  pointer  to  descendent  Retrieves  I  . 

I  pointer  to  descenoent  DELETES  I 

I  •  i 

1  •  • 

‘  t  » 

I  I 

I  pointer  to  DELETE  I 

i.mmmmmmmmmmmmmmmmmmmmmmmmmm^mmmmmm^ 

Elqure  22:  Tne  'erase.node'  with  all  option, 

B,  THE  CAPPING  PROCESS;  AM  EXAMPLE 

In  this  section,  «e  present  an  illustrative  exai^nie  of 
the  oarsinq  and  translation  processes  i>»lthin  tne  K^S, 
Recall  from  the  previous  chapter,  tnai  not  all  of  the 

features  of  CDDASYL  are  incorporated  in  our  soecif Icatlon, 
Additional! V,  since  we  have  thoroughly  covered  the  mappings 
In  the  orevlous  chapter,  we  do  not  discuss  these 
translations  In  detail. 

As  an  example  of  the  KMS  mapping  process,  we  use  a 
simple  CODASTL  voDiry  request.  we  begin  our  example  by 
snowing  tne  dml. statement  portion  of  tne  Khs,  ve  tnen  step 
througn  tne  grammar  and  demonstrate  relevant  portions  of  our 
design  In  a  system  specification  language  (SSLj,  The  reader 
should  note  that  tnrouahout  the  examnie,  we  only  show  the 
portions  of  the  SSL  that  would  actually  ne  executed.  The 
entire  desion  Is  shown  in  the  Appendix,  The  portion  of 

the  grammar  relevant  to  this  example  is  shown  In  Figure  23, 


In  Floure  23,  we  have  Included  the  oramna.  rules  onlv, 
not  the  code  to  be  invoiced  as  eacn  rule  is  satisfied. 


and 


statement:  ddl. statement 
I  dml 


dml:  dmi_statement 

I  dml  dml. statement 


dml. statement :  set. flag 
I  move 
I  get 
I  find 
I  store 
I  connect 
I  disconnect 
I  erase 
I  modify 
I  oerform.loop 
I  if.tnen 


modify:  MODIFY  item. list  record.tyoe 
I  voniFY  record. type 


item. list:  item. name 

I  item. list  COMMA  item. name 


record. tvne:  tofntifier 


item. name:  IDENTIFIER 


Figure  23:  The  kms  dmi. statement  Grammar, 


The  source  COPASYL  procedure  we  use  for  our  example  is: 


MOVE  ino  rn  oty  itv  sp 
modify  gty  in  sp. 


defore  divim  the  Af^DD  equivalent  of  this  request,  however, 
we  must  maxe  the  assumption  that  the  record  oelng  modi  tied 


Is  the  current  record  of  the  run  unit 


•He  also  assume  that 


the  database  key  for  this  record  is  10,  ■((Ith  these  two 
assumptions  In  mind,  the  A80I.  eaulvalent  of  the  modify 
statement  is; 

[UPDATE  ((TEMPLATE  =  SP)  and  (DBKEY  s  101) 

(QTY  s  100)1, 

For  the  sake  of  brevity  In  our  example,  we  will  not  do 
through  the  mapping  orocess  for  the  MOVE  statement.  The 
reader  need  only  be  aware  that  the  new  value  for  tne 
attribute  QTY  in  the  record  template  for  record  type  SP,  has 
teen  set  to  tne  value,  lOO,  oy  tne  previous 
par se/trans latlon ,  Mow,  we  may  oroceed  with  the  mapolng  of 
the  MODIFY  statement. 

At  tne  oeginninq  of  the  maoplnq  process,  tne  oarse 
descends  tne  grammar  hierarchy  searching  for  tokens  In  tne 
grammar  rules  which  match  those  In  the  Input,  Notice  that 
the  first  rule  to  be  tried  is  the  ddl-statement  rule.  As 
the  parse  descends  the  ddl.statement  rule,  hierarchically, 
there  are  no  tokens  which  match  the  examnle  inout  stream. 
Thus,  the  ddl«statement  rule  is  net  satisfied,  and  the  oarse 
begins  aoaln  at  the  oml  rule, 

When  the  dml  rule  is  called.  It  immediately  calls  the 
dml.statement  rule. 


dml. statement :  set. flag 
I  move 
I  get 
I  find 
I  store 
I  connect 
I  olsconnect 
I  erase 
I  modify 
I  perform. loop 
I  If. then 
;  . 


The  dml. statement  rule  then  calls  the  set.flaq  rule,  tne 
set. flag  rule  Is  not  satisfied,  however,  and  the  move  rule 
Is  called.  It  too.  Is  not  satisfied.  So,  the  process  of 
cliecklnq  each  successive  rule  Is  continued  until  we  reach 
the  following  rule: 


modify:  ‘^OUIFY 

< 

select. list  s  NULL 

Item. list  IN  record. tvoe 

< 

/*  error  checics  are  made  here  */ 
alloc  and  Init  new  'modify'  none 


for  (each  data. item  on  select-list) 
alloc  and  init  new  aodl.str 
/*  form  UPDATE  request  */ 
copy  "[Lif'DATE  ((TFaPLAi'E  s  'record. type' ) 
and  (OBXEY  =  CIT, rtdN.DNIT, dbKey) ) " 
to  abdl.str 

aet  'Item. value'  from  move. list 
concat  "( 'data. Item'  =  ' itcm.va lue ' ) ] 
to  abdl.str 

connect  abol.str  to  'modify'  node 
end. for 
end. else 
} 

I  'MODIFY  record. type 

;  , 

The  modify  rule  lootcs  for  the  tolcer,  ''ODIFY,  In  the  Input, 
Since  It  Is  Present,  the  first  portion  of  the  rule  matcnes, 
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and  the  code  followlnq  the  token  In  the  rule  is  invoked. 
This  code  simply  resets  a  local  list  which  win  eventually 
contain  tne  names  o£  the  data  items  which  are  to  oe 
modified. 

The  next  rule  called  is  the  rule.  This  rule 
searches  for  a  list  of  identifiers  in  the  input  by  calllm 
the  item. name  rule,  and  recursively  calllm  item.ilst,  as 
indicated.  In  our  example,  the  sinyle  iaentlfier,  dTY, 
satisfies  the  first  portion  of  this  ruie,  namely,  item. name. 
Thus,  the  item. list  rule  is  satisfiea.  The  syntax  for  the 
item. list  rule  is: 


item. list:  item. name 

< 

arid  the  item.name 
to  select»llst 

> 

item. list  COiiMA  item. name 
( 

add  succesive 

Item.name  to  selec.llst 

} 


The  next  portion  of  the  modify  rule  is  the  token,  IN, 
This  token  matches  the  token,  in,  in  the  Inout  stream,  and 
the  Parse  continues,  "Inally,  the  last  portion  or  tne 
modify  rule  which  must  oe  satisfied  is  the  cecacd«t;tBft  rule. 
This  rule  is  satisfied  hy  matchlnq  the  identifier,  SP,  in 
the  input,  vlth  the  token,  lOK'tTlf'reo,  in  the  record.type 
rtile.  After  matchlnq  these  two,  tne  entire  modify  rule  is 


satisfied,  and  the  invocation  of  the  remainlnq  mappinq  and 
translation  code  following  the  rule  taices  place. 

The  mapolnq  and  translation  occurs  as  tollorws.  First,  a 
series  of  checks  are  made  to  determine  If  the  record  being 
modified  is  the  current  record  of  the  run  unit.  If  the  new 
value(s)  have  been  placed  In  the  record  temnlate,  and  If  all 
of  the  Items  Identified  In  the  Item  list  belong  to  the 
record  in  question.  Then,  a  modify  node  is  created. 
Following  this  step,  an  UPDATE  request  Is  generated  for  each 
of  the  data  items  being  modified.  Finally,  each  of  tne 
update  requests  are  connected  to  the  modify  node  for 
execution  oy  the  KC,  with  the  mapoinq  and  translation  code 
executed ,  the  modify  rule  Is  completely  satisfied,  and 
control  propagates  back  up  the  grammar  nlerarchy  to  the  dmi 
rule  which  checks  tor  more  Inout, 

As  one  can  see,  quite  a  slanlflcant  amount  of  work  Is 
done  by  the  KdS  in  oreoarina  requests  for  use  bv  the  fc, 
feel  that  by  adequately  provldinq  information  to  tne  KC,  we 
greatly  reduce  the  amnunt  of  work  that  must  be  done  by  the 

KC,  This  means  less  coding  tor  tiie  Implementor  and  Should 

lead  to  less  complexity  in  the  KC, 

C,  THE  KEHNEL  CL'NTHULLER  (KC) 

The  KC  Is  the  third  module  In  the  i-d.DS  CCOASYU 

Interface,  It  Is  called  oy  the  lanauage  Interface  layer 

CLih)  when  a  new  database  Is  oelnq  loaded,  and  is  called  oy 
tne  kernel  mapping  system  (KM3)  when  an  existing  database  Is 


being  manipulated.  The  KC  is  the  module  which  performs  the 
tasK  of  controlling  the  submission  of  ABOL  transactions  to 


the  rnultl-bacKend  database  system  (i«Bhsj  for  orocessino. 
Implementations  of  the  KC  for  the  DL/I  and  SQL  interfaces 
can  be  found  In  TKef,  5:pp,  84-105J  and  tRef,  6;pd,  , 
respectively. 

The  KC  must  perform  the  following  functions:  Cl)  submit 
transactions  to  the  mBDS,  (2)  receive  and  store  results  of 
transactions,  (3)  update  the  currency  indicator  taole,  and 
(1)  cause  the  orooer  data  to  oe  returned  to  the  user, 

1,  lue  stsuctuse  at  taa  nc 

Because  of  the  large  number  of  types  of  transactions 
that  the  KC  must  process,  we  suggest  that  the  overall, 
structure  of  tne  KC  oe  based  on  tne  "case**  control 
structure.  At  tne  top  of  tne  control  structure  is  a  master 
control  procedure  which  Is  responsible  for  initialization  of 
variaoles,  pointers,  and  data  structures,  as  well  as, 
necidlncj  the  type  of  ABHL  transaction  that  Is  being 
processed,  ►’ecall  that  there  are  two  major  tyoes  of 
transactions ,  creation  of  a  pew  dataoase,  and  manipulation 
of  an  existing  dut.abase.  Thus,  a  two  ele.ment  case  is 
regulred  in  the  master  control  procedure.  These  cases  are 
then  used  to  call  subsequent  procedures  and  functions  vnlch 
handle  tne  transactions  which  fail  under  the  above 
cateoor les , 


i 


. 
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a.  Creation  of  a  New  Database 


The  creation  of  a  new  dataoase  is  the  least 
difficult  transaction  that  the  KC  win  nanile,  it  involves 
loading  the  CDDASYL  schema  created  by  the  KMS  into  the  kuS 
(MBDS),  In  Its  attribute-eased  form*  It  is  also  responsiele 
for  mass  storaoe  of  new  records  during  a  database  creation 
transaction.  Thus,  the  KC  must  also  asslan  database  keys  to 
the  new  records  throuohout  this  process. 

Currently,  work  Is  being  done  on  the  algorithms 
necessary  to  accomplish  the  transformations  above  and  tne 
mass  storage  requirement.  This  work  will  not  oe  completed 
in  time  for  Inclusion  in  this  thesis.  Suffice  it  to  say, 
however,  that  once  the  work  is  completed,  the  only 
requirement  of  the  kC  in  this  case,  is  to  call  a  procedure 
to  load  the  database  schema,  call  a  procedure  to  load  the 
dataoase  descriptor  file,  and  then  call  a  orocedure  to  load 
the  new  database.  hnce  these  procedures  are  executea, 
control  Is  returned  to  the  LTL, 

b.  Manipulation  of  an  Existing  Database 

The  manipulation  of  an  existing  database  can 


also  he 

divided 

Into 

SUP 

-cases,  Tnere  are 

the  data 

retrieval 

r enuests 

and 

tne 

database  unoate 

requests . 

However , 

all  of 

these 

can 

he  handled  oy  a 

single  case 

structure 

,  «ecall 

that 

each 

time  the  KC  is 

call  el,  a 

reouest 

node  of 

some 

tyre 

is  made  available 

tu  tne  KC, 

Tnese  reouest  nodes  are  then  used  to  determine  which  ootion 


within  the  case  structure  to  execute 


ihe  structure  is 


Illustrated  in  Figure  24,  in  the  following  sections,  we 
present  the  orocedural  requirements  for  each  type  of  data 
manipulation  transaction. 


case  00. type  of 

create. db:  call  load.schema 

call  load. descriptors 
call  load.do.recs 

a 

§ 

find:  case  tyne  of 

any;  call  find. any 
current;  call  find. current 
duplicate;  call  find. duplicate 
( first, last , 

next, prior):  call  find.conseg 
owner:  call  find. owner 
end. case; 

(connect , 

disconnect, modify) :  call  update. db 

f 

store;  call  store.rec 

f 

erase:  call  delete-recs 

a 

I 

get:  call  get.rec 


Figure  24:  The  KC  Control  Structure, 


(1)  X&a  SXttQ  esaccduses.  Tnere  are  six  basic 
types  of  FIND  requests  utilized  in  our  system.  The  first  of 
these  is  the  FI^D  AuY  request,  upon  encountering  a 
find. node  whose  tyre  field  is  ANY,  toe  find. any  procedure  is 
called.  This  procedure  sets  up  the  request  ouffer  to 
receive  any  results  that  may  oe  returned,  it  men  Issues 
tne  request  to  the  KDS,  Uoon  return  from  the  KDS,  the 
find. any  procedure  must  update  the  cif,  based  on  the  type 


and  database  Key  of  the  record  that  Is  the  first  record  in 


the  request  buffer.  A  pointer  Is  then  set  to  point  to  this 


record  In  preparation  for  returnlnq  it  to  the  user.  The 
record  is  not  returned  though,  unless  the  user  issues  a  GET 
request. 

If  the  request  is  a  find  CURPENT  request, 
the  find. current  procedure  is  called.  Its  job  Is  quite 
easy.  It  must  simply  update  the  CIT,  oy  settinq  the  current 
of  run  unit  Indicator  to  the  type  and  database  icey  of  the 
current  record  of  the  set  tyoe  specified  In  the  request 
node. 

When  the  request  Is  a  EINP  duplicate 
request,  the  f Ind.dupiicate  oroceoure  is  called.  This 
procedure  assumes  that  the  records  oelnq  requested  are 
already  in  a  reouest  buffer.  Thus,  the  only  information 
required  from  the  flnd.node  Is  the  record.type  oeinn 
searched  for,  the  set.type  of  Interest,  and  the  data  item 
values  on  which  the  search  is  based.  The  procedure  locates 
tne  request  buffer,  and  sets  a  pointer  to  point  to  the  first 
duplicate  record  found.  This  record  then  becomes  the  record 
returned  when  the  user  Issues  a  GET  request.  The  procedure 
also  updates  the  CIT  accordingly. 

The  next  type  of  Fl.iO  request  is  the  fimD 
FIRST,  LAST,  UEXT,  or  PRIOR,  In  these  cases,  if  the  tyoe  is 
first,  last,  next,  or  prior,  the  flnd.conseq  procedure  is 
called.  It  bases  Its  oerformance  on  tne  type  of  the 
flnd.node.  If  the  type  is  next  or  prior,  tne  procedure 


assumes  that  the  records  are  already  in  a  request  outter 


It  looks  for  the  correct  request  ouffer  based  on  the 
record.tyoe  specified  In  the  find. node,  and  sets  a  pointer 
to  point  to  the  next  or  prior  record  relative  to  the  current 
record  of  the  set  type  this  buffer  Is  holdinq.  In  other 
words,  each  record  in  the  buffer  Is  a  member  ot  the  current 
set  type  occurrence  and  the  flnd.conseq  procedure  simoiy 
points  to  the  record  before  or  after  tne  current  record  for 
that  set.  Once  again,  this  is  the  record  returned  when  the 
user  issues  a  GET  request. 

If  the  type  of  the  i-'liJO  is  first  or  last, 
the  flnd.conseq  procedure  does  the  following.  First,  it 
checks  to  see  if  a  request  buffer  exists  for  the  set  type 
requested  in  the  find. node.  If  no  such  buffer  exists,  the 
procedure  creates  a  request  buffer  and  Issues  the  RFTRiEyE 
request  attached  to  the  flnd.node.  The  results  of  the 
request  are  then  placed  In  the  nr^  request  buffer,  and  a 
pointer  is  set  to  point  to  the  "first"  or  "last"  record  in 
the  set  for  return  to  the  user. 

The  next  type  of  find  request  is  tne  fii'jd 
O^NEH,  vhen  this  is  the  tyoe  of  tne  tlnd.noae,  the 
find. owner  orocedure  is  called.  It's  function  is  fairly 
str alqnttorward ,  A  request  buffer  is  created  to  hold  the 
record  that  is  the  owner  record  of  the  set  type  indicated  in 
the  flnd.node.  The  flnd.owner  proceaure  tnen  Issues  the 
retrieve  request  attached  to  tne  flnd.node,  and  prepares  the 


record  for  return  to  tne  user 


The  final  tyoe  of  request,  expected  by 
the  KC,  Is  the  FldD  wITHiM  CLRPENT  request,  Tn  this  case, 
the  find. within  procedure  is  called.  The  procedure  creates 
a  request  puffer  for  the  storaoc  of  records  returned  and 
issues  the  RETRILVE  request  associated  *1 th  the  current 
find. node,  i\tiain,  a  pointer  is  set  to  point  to  the  first 
record  in  the  reauest  buffer  In  order  that  this  record  -niunt 
he  returned  when  a  GET  request  is  Issued  by  the  user.  It 
Should  be  noted  that  in  each  case  above,  the  CIT  is  updated 
unless  a  currency  suppression  list  nas  been  attached  to  tne 
flno.node  in  question, 

(2)  cciitiECi,  Discatitisci,  aad  nanzsi 
2sacO(lufia&,  The  connect,  oisCOnncct,  and  HoniFY  requests 
are  handled  by  the  KC  in  the  same  qenerai  manner,  when 
either  a  modify. noae,  a  connect.node,  or  a  disconnect. node 
is  encountered  by  tne  KC,  tne  procedure,  update. do,  is 
called.  If  the  node  is  a  modlfy.node,  tne  KC  simoly  submits 
the  attached  abdL  UPOATE  requests  to  the  KOS  for  execution. 
After  execution,  control  Is  returned  to  the  LII., 

If  tne  node  oassed  to  ornceddure  update.db 
is  a  connect.node  nr  a  dlsconnect-node ,  all  of  the  above 
aoplies,  except  that  before  qivinq  control  to  the  LIL,  the 
KC  must  UDdate  the  CIT,  '’/hen  a  record  is  connected  to  a  set 
type,  that  record  becomes  the  current  record  of  the  set 
type,  '•hen  a  record  is  -Hsconnected  from  a  set  tyoe,  the 
entry  In  for  that  set  tyoe  In  tne  Cl f  is  set  to  null  and 
remains  so  until  another  record  of  the  set  tyoe  is  accessed. 


(3)  lh&  SXQRS 


Rsocadusa 


When 


the 


KC 


recognizes  a  store.node,  the  procedure  store.rec  is  called. 
The  first  task  performed  by  store.rec  Is  to  execute  tne 
first  RETRIEVE  request  attached  to  the  node.  This  request 
determines  If  there  are  records  In  tne  database  wnlch  have 
attribute  values  that  are  not  to  pe  duolicated.  If  the 
request  ouffer  created  for  this  RETRIEVE  is  Boa-CBBty:  at  the 
end  of  execution,  there  Is  an  error.  If  the  request  ouffer 
is  acQ&R  ,  then  store. rec  performs  In  the  following  manner. 
For  each  RETRIEVE  reouest  on  the  set  select  RETRIEVE  list,  a 
file  buffer  Is  created  and  the  RETRIEVE  request  Is  issued. 
These  requests  return  the  database  keys  of  tne  owners  of  the 
set  occurrences  to  which  the  new  record  belongs. 

After  execution  of  the  set  select  retrieve 
list,  the  procedure  store. rec  then  assigns  a  database  key  to 
the  new  record,  and  proceeds  to  complete  the  INSERT  request 
attached  to  the  store.node.  It  is  very  important  that  the 
order  in  which  tne  database  keys  are  accessed  from  tne 
request  buffer  match  the  order  of  the  attributes, 
,  set.tyoel ,  In  the  INSERT  request.  The  insert  request 
Is  tnen  Issued,  now,  because  we  nave  not  accessed  this 
record  orevlously,  and  it  has  become  the  current  of  run 
unit,  store. rec  must  provide  a  buffer  to  hold  this  record  in 
case  a  GET  request  is  issued  immediately  following  the  STORE 
request,  An  example  of  this  process  is  warranted  at  this 


MOVE  'S5'  TO  SNO  IN  Sp 
MOVE  'Pfi'  TO  PNO  IN  SP 
MOVE  700  TO  OTY  IN  SP 
MOVE  'S5'  TO  SNO  IN  S 
MOVE  'P6'  TO  PNO  IN  P 
STQPE  SP 


The  first  three  moves  initialize  the  new 
record's  data  values.  The  next  two  move's  are  used  to  aid 
In  determlnim  which  s  and  P  occurrences  the  new  record 
belongs  to,  because  Its  set  insertion  mode  was  declared  to 
be  automatic.  The  Kms  takes  this  information  and  the  SIOke 
SP  statement,  and  oroduces  a  store.node  containing  the 
following: 


(Puollcates  retrieve  request) 

RETRIEVE  ((TYPE  =  SP)  and  (SMO  =  Ss)  and  (PNO  s  P6)) 
(DOKEY) 

(List  of  RETRIEVES  to  get  owner  DBkEYs) 

RETRIEVE  ((TYPE  s  S)  and  (SNO  a  SS))  (DRKEY) 

RETRIEVE  ((TYPE  a  P)  and  (PNC  a  p6))  (DBKEY) 

(INSERT  request  for  new  record) 

INSERT  C<TY?E,SP>,<nBKEY,<'**>,<SNO,S5>,<PNO,P6>, 
<MEMPER,S-SP,l‘***>,<MEMB£R,P-SP, 


We  assume,  for  tne  sake  of  our  example, 
that  the  hPKEYs  for  the  owner  records  are  lh(S)  and  12(p), 
ano  that  the  npKEY  of  tne  new  record  Is  Ve  also  assume 
tnat  there  Is  no  duplicate  SP  record  in  the  database.  So, 
wnen  store«rec  issues  the  first  RETRIEVE,  the  request  buffer 
returned  Is  empty. 

Store. rec  then  proceeds  to  execute  the  list 
of  retrieves  that  return  the  owner  rtfikEYs  of  tne  new  record. 
It  creates  a  reotjest  buffer  tor  the  first  retrieve  on  tne 


list  and  Issues  the  request.  Once  the  first  request  Is 
executed,  a  buffer  is  created  for  the  second  reauest,  and 
that  request  is  executed.  The  issuance  of  these  RETRitVts 
produces  the  results  in  the  request  buffers  depicted  in 
Figure  25,  The  procedure  store«rec  no**  ta<es  tne  new  dbkey 
value,  and  the  information  from  the  request  buffers  and 
conoletes  the  INSERT  request, 

I  <  10  >  I 
I  I 

Buf  1 

I  <  12  >  » 

I  I 

Huf2 

Figure  25:  Bufl  and  3uf2  After  Execution, 

The  final  form  of  the  INSERT  request  Is: 

I*'SERT  (<TYPE,SP>,<nBK£Y,98>,<SN0,55>,<PN0,o6>, 
<membER,S-SF,  10>,<ME:MrtER,P-SP,  1?>) 

The  INSERT  request  ts  then  Issued  to  tne  KDS,  If  no 
currency  suooresslon  list  is  attached  to  the  store.node ,  tne 
CTT  Is  undated  to  reflect  a  cnanqe  in  the  S-SP  ana  P-SP 
currencv  as  well  as,  the  current  of  run  unit,  A  request 
buffer  Is  also  created,  and  tne  record  is  stored  in  the 
buffer.  As  one  can  see,  tne  store-rec  procedure  can  he  a 


very  comprehensive  one 


(4)  Zbe  £E&S£  S£acadu££i&«  The  erase  request  Is 


handled  by  the  procedure,  delete.recs.  If  the  tyre  of  the 
erase.node  Is  null,  then  delet.recs  oroceeds  In  tne 
followlnq  manner.  First,  a  request  buffer  is  created,  and 
the  RETRIEVE  request  attached  to  the  erase.node  is  Issued  to 
the  KDS,  This  request  determines  If  the  record  oeim 
deleted  is  an  o*(ner  of  a  non-empty  set.  If  the  request 
buffer  is  not  empty  after  execution  of  the  RETRIEVE,  then 
the  erase  falls,  and  we  have  an  error  condition.  If  tne 
request  buffer  is  empty  after  execution  of  tne  RETkitVfe., 
then  delete. recs  Issues  tne  DELETE  request  attached  to  tne 
erase. node,  mis  request  deletes  tne  current  record  of  tne 
run  unit,,-,  After  the  deletions,  delete. recs  uodates  the  CIT 
by  settlnq  the  current  of  run  unit  indicator  to  UULL, 

Sliould  the  tvpe  of  the  erase. node  be  all, 
we  have  a  different  sequence  of  events.  The  delete-recs 
procedure  must  create  reauest  buffers  for  each  RETRIEVE 
request  on  the  descendent  retrieve  list  in  tne  erase. node. 
It  must  then  issue  each  of  these  RETRIEVES  storing  the 
results,  returned  DHKEYs,  in  the  prooer  request  buffer. 
After  the  list  of  retrieves  has  been  issuea,  the  delete. recs 
orocedure  then  completes  the  delete  requests  attached  to  tne 
erase.node  and  issues  each  DELETE  request  to  the  Khs  for 
execution.  Once  again,  the  CIT  is  uodated  to  reflect  tne 
chanqe  in  currency  i,e,,  current  of  set. types  become  nolL  as 
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aorroprlate 


Ci)  Xbfi  sex  Bcacaducft 


The  GET  reauest  is 


handled  hy  the  get.rec  procedure.  This  procedure  nas  a 
relatively  easy  task.  It  sltnoly  looks  at  the  -type  of  the 
get.node,  examines  the  record.type  Involved,  and  retrieves 
either  the  entire  record  of  specific  fields  of  the  record 
from  the  request  puffer  In  which  the  record  resides,  Tne 
GET  request  operates  on  the  current  of  run  unit,  do,  tne 
request  buffer  In  question  should  be  the  request  buffer 
containing  the  current  record  of  the  run  unit,  provided  tne 
current  record  of  tne  run  unit  Is  not  finally,  the 
reader  snouid  note  that  with  each  of  the  aoove  orocedtires, 


deallocation 

of  request  buffers 

when  they  are 

no 

longer 

required,  is 

also  an  important 

consideration 

In 

this 

process 


VI 


CQUCLUSICUS 


As  (Tientloned  in  the  introduction,  the  conventional 
approach  to  database  system  development  has  resulted  In 
numerous  single-model,  single-language  systems  witn  little, 
if  any,  fiexlnllity  or  extensibility.  In  addition,  these 
systems  are  slow  compared  to  the  system  proposed  dv  tnls 
research  effort,  Gur  system,  the  multi-lingual  database 
system  (mlds),  provides  an  alternative  to  the  development  of 
seperate  stand-alone  database  systems  wnich  use  single  data 
models.  The  MLOS  <*111  bring  flexibility,  extensibility,  and 
efficiency  to  the  world  of  database  management.  The  '^LiDS 
will  be  able  to  execute  transactions  written  in  any  of  four 
well-known  and  Important  data  lannuaaes,  namely,  Dt</I,  aOL, 
CHDASYL,  and  Daplex, 

In  this  tnesis,  we  have  presented  a  methodology  for 
supporting  network  database  management  within  tne  ’ihhs. 
Specifically,  we  nave  provided  a  data  model  transformation 
strategy,  and  a  oata  language  translation  strategy  for  tne 
network  data  model  and  tne  CCuA5y[,  data  language, 
r esoectl vely ,  we  have  presented  a  design  specification  for 
the  kernel  maDolng  system  (KhS)  to  be  used  in  the  CQPASKL 
interface,  A  discussion  of  the  concepts  involved  and  the 
data  structures  necessary  for  the  interface  to  work  prooerly 
has  also  seen  presented. 


One  of  the  deslon  goals  of  this  project  was  to  make  the 
Interface  as  compatible  as  possible  with  the  designs  of  the 
DL/I  and  soil  interfaces  in  order  to  fully  utilize  existing 
software.  The  Daplex  Interface  is  not  mentioned  here, 
because  it  is  being  developed  In  parallel  with  the  CUOASYL 
Interface,  Ry  pursuing  this  goal,  we  also  eliminate  the 
need  for  changes  in  the  VHDS  and  the  AdhL,  Thus,  it  is 
recommendeo  tnat  the  implementation  of  tne  CODASYL  Interface 
follow  closely,  the  Implementations  of  the  00/1  and  SOL 
Interfaces,  The  1 mplementor ( s )  Should  pay  particular 
attention  to  any  commonalities  between  funtlons  and  data 
structures , 

we  feel  tnat  the  work  presented  herein  Is  sufficient  for 
implementation  of  the  COOASYL  Interface,  a1i  that  remains 
is  for  the  code  to  be  written,  and  Placed  in  the  host 
computer,  once  the  COOASYL  interface  and  the  oaplex 
interface  have  been  completely  imp lementeo ,  tne  system 
Should  be  tested  as  a  complete  system  for  projected 
efficiency,  effectiveness,  and  responsiveness  to  user  needs. 
It  is  anticipate  !  tnat  this  researcn  and  aeveiobment  effort 
will  ultimately  result  in  a  new  era  for  aatabase  management 
that  will  allow  for  increased  productivity  and  orotitaoliltY 


in  the  marketplace 


APPENDIX  -  THE  KMS  PROGRAM  SPECIFIC  A  TIOSS 

Currency  Indicator  Table 

References  made  in  the  following  specification  to  CIT  refer  to  the  Currency  Indicator  Table. 
This  table  consists  of  structures  that  hold  information  identifying  the  current  record  of  record- 
type,  set-type,  and  run-unit  (run-unit  is  the  application  program  being  run).  The  following  is  the 
proposed  structure  for  this  table  [Ref.  13]. 
struct  CIT 
{ 

struct  RUN-UNIT  *run; 
struct  rec-type-node  *next-rec-type; 
struct  set-type-node  *next-set-type; 

} 

struct  RUN-UNIT 

{ 

char  rec-typej  [; 
int  dbkey; 

} 

For  each  record  type  in  schema: 
struct  rec-type-node 
{ 

char  type]  |; 

int  dbkey; 

struct  rec-type-node  *next-rec-type; 


For  each  set  type  in  schema: 
struct  set-type-node 
{ 

boolean  OWNER; 

char  TYPE]  I; 

int  dbkey; 

char  member]  j; 

char  owner]  j; 

int  owner-dbkey; 

struct  set-type-node  *next-set-type; 


.  1 


V.: 


boolean;  first-move  =  TRUE  /*  flag  for  MOVE  operation  */ 
boolean:  first-time  /*  general  purpose  flag  */ 
boolean:  sys-flag-value  /*  boolean  value  of  system  flags  */ 
ptr;  curr-temp-rec  j*  ptr  to  last  record  added  to  move-list  */ 
ptr;  curr-temp-item  /*  ptr  to  next  item  node  to  be  added  to 
record-template  node  of  movelist  */ 
list:  suppression-list  /*  list  of  record  types  and/or  set  types  */ 

for  which  currency  updates  are  suppressed  */ 
list:  select-list  /*  list  of  data  items  used  for  record  section  */ 
list:  connect-list  /*  list  of  sets  to  which  current  of  run 

unit  is  to  be  connected  or  disconnected  */ 
list:  tgt-list  j*  list  of  attribute  names  to  be  accessed  */ 

list:  move-list  *  list  of  record  templates  used  with 

MOVE  statement  *  j 

list:  curr-non-dup-list  /*  list  of  data  items  for  which  duplicates 
are  not  allowed  in  current  record-type  */ 
int:  level-number  /*  level  of  data  item  in  record  types  */ 
char;  member-type  /*  siring  variable  to  hold  a  name  */ 


THE  DESIGN  AND  flNflLVSIS  OF  R  METUORK  INTERFACE  FOR  THE 
HULTI-LINOUAL  DATABASE  SVSTEHtU)  NAVAL  POSTGRADUATE 
SCHOOL  NONTEREV  CA  C  R  UORTHERLV  DEC  OS 


UNCLASSIFIED 


F/G  9/2 


start  statement 


statement;  ddl-statement 
dml 

dml;  dml-statement 
dml  dml-statement 

t 

ddl-statement;  schema-defn  record-list  set-list 


schema-defn;  SCHEMA  NAME  IS  schema-name  SEMI-COLON 

{ 

locate  db-id  schema  header  node 
if  (db  names  do  not  match) 
print  ("Error-given  db-name  doesn’t 
match  name  in  file") 
perform  yyerror() 
return 
end-if 

initialize  db-key  -  *  starting  value  is  1  ’y' 

} 

record-list:  record-desc 

{ 

set  db-id  node  ndn-first-rec  ptr 

} 

record-list  record-desc 

{ 

connect  successive  record  nodes 

} 


record-desc:  record  data-item-list 

{ 

rurr-non-dup-list  =  NULL 

} 


record:  RECORD  NAME  IS 

{ 

allocate  and  init  a  new 
record  node  (NREC-NODE) 
allocate  curr-non-dup-list 
db-id-node  ndn-num-rec^-t- 
} 

record-spec 


•V-W 


record-spec;  record-type 

{ 

if  (record-type  not  defined  yet) 
copy  record-type  to  current 
record  node  (NREC-XODE) 
make  this  the  current  record  node 
end-if 
else 

print  ("Error- ’record-type’  record 
doubly  defined") 
perform  yyerror() 
return 
end-else 
} 

SEMI-COLON  duplicates- list 


set-list:  empty 
sel-desc 

set  db-ld  node  ndn-first-set  ptr 

} 

set -list  set-desc 

{ 

connect  successive  set  node(s) 

} 


set-desc:  set-desig  owner-spec  member-spec 


set-desig:  SET  NAME  IS 

{ 

allocate  and  init  a  new  set  node  (NSET-NODE) 
db-id-node  ndn-num-set-r-^ 

} 

set-type 

{ 

if  (set-type  not  yet  defined) 
copy  set-type  to  current  set  node  (nsn-name) 
establish  curr-set-ptr 
end-if 
else 

print  ("Error-'set-type‘  set  doubly  defined  in  db") 
perform  yyerror() 
end-else 
} 

SEMI-COLON 


•  4.  • 


owner-spec:  OWNER  IS  aa  SEMI-COLON 


aa:  record-type 

{ 

if  (record-type  not  defined) 
print  ("Error- ’record- type’  record  does  not  exist") 
perform  yyerror() 
return 
end-if 
else 

copy  record-type  to  current  set  node  (nsn-owner-name) 
locate  record-type  node 
nsn-owner(ptr)  -  record-type  node 
end-else 


SYSTEM 


member-spec:  MEMBER  IS  record-type 

{ 

if  (record-type  not  defined) 
print  (" Error- ’record-type’  record  does  not  exist") 
perform  y y error) ) 
return 
end-if 
else 

copy  record-type  to  current  set  node  (nsn-member-name) 
locate  record-type  node 
nsn-member(ptr)  —  record-type  node 
end-else 
} 

SEMI-COLON  insert-clause  retention-clause 

{ 

alloc  set-select  node 

} 

set-select-clause  SEMI-COLON 


■  ■ 
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duplicates-list:  empty 

dupl  SEMI-COLON 


dupl:  duplicate-spec 

dupl  duplicate-spec 


duplicate-spec:  DUPLICATES  ARE  NOT  ALLOWED  FOR  item-spec 
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item-spec;  item-name 

{ 

alloc  new  non-dup  node 
copy  item-name  to  non-dup  node 
add  non-dup  node  to  curr-non-dup-list 
} 

item-spec  COMMA  item-name 

{ 

alloc  successive  non-dup  nodes 
copy  successive  item-names  to  non-dup  nodes 
add  successive  non-dup  nodes  to  curr-non-dup-list 
} 


data-item-list;  item-desc 

{ 

connect  new  attr-node  to  record-node 

} 

data-item-list  item-desc 

{ 

connect  successive  attr-node{s)  to  record-node 

} 


k  .1 


item-desc:  level-num 


allocate  and  init  a  new  attr-node  (NATTR-NODE) 
NATTR-NODE  nan- level-num  =  level-number 
record-node  nrn-num-attr— -i- 
} 

data- item-desc 

{ 

if  (nan-level-num  =  level  number  of  current  attribute  node) 
connect  new  attr  node  to  current  atir  node 
if  (nan-level-number  >  1) 
connect  nan-parent  ptr  of  new  node 
end-if 
end-if 

else  if  (nan-level-number  >  level  number  of  current  attr  node) 
connect  nan-child  ptr  of  current  attr  node  to  new  attr  node 
connect  nan-parent  ptr  of  new  attr  node  to  current  attr  node 
end-else-if 
else 

locate  last  attr  node  with  same  level  number 
set  that  node’s  nan-next-attr  ptr  to  the  new  attr  node 
update  current  attr  pointer 
end-else 
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data-item-desc;  item-name 

{ 

copy  item-name  to  attr-node  (NATTR-NODE) 
if  (item-name  not  on  curr-non-dup-list) 
attr-node  nan-dup-flag  -  1 
end- if 
} 

SEMI-COLON  dala-type  PERIOD 


level-num;  empty 

{ 

level-number  =1  /*  default  value  * 

} 

INTEGER 

{ 

level-number  =  INTEGER 

} 


data-tvpe  CHARACTER  INTEGER 

{ 

attr-node  nan-lengthl  =  INTEGER 
attr-node  nan-length2  =  0 
attr-node  nan-type  =  ’c’ 


FIXED  INTEGER 


attr-node  nan-lengthi  =  INTEGER 
attr-node  nan-Iength2  =  0 
attr-node  nan-type  =  ’i’ 

} 

FIXED  INTEGER 


attr-node  nan-lengthl  =  INTEGER 

) 

INTEGER 

{ 

attr-node  nan-length2  =  INTEGER 
attr-node  nan-type  =  T 
} 
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set-select-spec:  VALL  E  OF  item-name  IN  record-type 


{ 

if(  valid-attr(item-name. record-type)) 
copy  ’v’  to  set-select  node  select-mode 
copy  item-name  to  set-select  node  item-name 
copy  record-type  to  set-select  node  record  I 
copy  BLANK  to  set-select  node  record2 
end-if 
else 

print("Error- ’item-name’  not  valid  for  ’record-type’") 
perform  yyerror() 
return 
end-else 
} 

STRUCTURAL  item-name  IN  record-type 

{ 

if(valid-attr(item-name, record-type)) 
copy  ’s’  to  set-select  node  select-mode 
copy  item-name  to  set-select  node  item-name 
copy  record-type  to  set-select  node  record  1 
end-if 
else 

print("Error-’item-name’  not  valid  for  ’record-type’") 

perform  yyerror() 

return 

} 

EQ  item-name  IN  record-type 

{ 

if(previous  item-name  equals  this  item-name) 
if(valid-attr(item-name, record-type)) 
copy  record-type  to  set-select  node  record2 
end-if 
else 

print("Error-’item-name’  is  not  valid  for  ’record-type’") 
perform  yyerror() 
return 
end-if 
else 

print("Error-’item-name’  items  do  not  match") 
perform  yyerror() 
return 
end-else 
} 

APPLICATION 

{ 

copy  a'  to  set-select  node  select-mode 
copy  BLANK  to  record  1,  record2.  item-name 


dml-statement:  set-flag 
I  move 
'  get 
I  find 
I  store 
[  connect 
I  disconnect 
[  erase 
I  modify 

\  perform-loop  /*  not  designed  * /' 
I  if-then  /'*  not  designed  */ 


set-flag:  MOVE  f-value  TO  f-name 


f-value:  YES 


{ 

sys-flag-value  =  TRUE 

} 

NO 


{ 

sys-flag-value  =  FALSE 

} 


f-name:  EOF 

{ 

eof  =  sys-flag-value 


NOTFOUND 

{ 


notfound  =  sys-flag-value 


I*  The  MOVE  statement  is  a  COBOL  assignment  statement  that  assigns  a  */ 
/  *  value  to  a  particular  data  field  in  a  record  template.  We  use  a  ’ 

I*  list  structure  for  this  purpose.  */ 

move;  MOVE  item-value 

{ 

if  (first-move  =  TRUE) 
alloc  and  init  move-list 
first-move  =  FALSE 
end-if 

create  new  data-item-node 

copy  ’item-value’  to  value  field  in  data-item-node 
establish  curr-temp-item  pointer 
} 

TO  item-name 

{ 

copy  ’item-name’  to  name  field  in  data-item-node 

} 

IN  record-tvpe 

{ 

if  (item-name  not  in  record-type  for  current  schema) 
perform  error(2) 
return 
end-if 

else  if  (’record-type’  node  on  move-list) 

connect  curr-temp-item  to  record-template  node 
end-else-if 
else 

create  new  record-template  node 

copy  ’record-type’  to  name  field  of  record-template  node 
connect  curr-temp-item  to  record-template  node 
add  record-template  node  to  move-list 
update  curr-temp-rec  pointer 
end-else 


/  *  The  GET  statement  takes  the  entire  current  record  of  the  run  unit  *  ' 
/  *  or  specified  data  fields  of  the  current  record  of  the  run  unit  *, 

I  *  and  returns  the  values  to  the  user.  *  ■ 

get;  GET 

{ 

alloc  and  init  new  gel’  node 
select-list  =  NULL  *  reset  select-list  */ 

t 

mm 


JL 


mm:  item-list  IN  record-type 

{ 

if  (’record-type'  is  not  equal  to  CIT.RL’N-L  NIT. type) 
perform  error(3) 
return 
end-if 
else 

get-type  =  ITEMS  in  get  node 
copy  record-type  to  get  node 
for  (each  data-item  on  item-list) 
if  (’data-item’  is  not  defined  for  record-type) 
perform  error(2) 
return 
end-if 

else  *  create  pseudo  tgt-list  */ 
copy  data-item  to  get  node 
end-else 
end-for 
end-else 
} 

record-tvpe 
{  ■ 

if  (’record-type’  is  not  equal  to  CIT. RUN-UNIT. type) 
perform  error(3) 
return 
end-if 
else 

get-type  =  RETURN-ALL  in  get  node 
copy  ’record-type’  to  get  node 
end-else 
} 

empty 

{ 

get-type  =  RETURN-ALL  in  get  node 
copy  CIT. RUN-UNIT. type  to  get  node 
} 


*  The  FIND  statements  establish  the  current  of  run  unit,  record  type,  */ 

*  and  set  type.  */ 


find:  FIND  record-select ion-expr  curr-suppression 


'  The  FIND  ANY  means:  find  any  record  of  type  record-type  whose  * 

*  values  for  iteml  through  ilemn  match  those  in  that  record's 

*  template  in  the  user  work  area.  * 

record-selection-expr:  .ANY  record-tvpe 

{ 

if  (’record-type’  record-template  node  is  not 
on  move-list) 
perform  error{  1 ) 
return 
else 

alloc  and  init  new  ’find’  node 
find-type  =  .A.N'Y  in  find  node 
copy  record-type  to  find  node 
alloc  and  init  new  abdl-str 
alloc  and  init  new  tgt-list 
*  begin  forming  a  RETRIEVE  request  *, 
copy  "  RETRIEVE  ((TE.MPLATE  -  ’record-type' 
to  abdl-str 
end-if 

select-list  =  .NT'LL 

} 

USI.N'G  item-list  IN'  record-type 

{ 

if  (’record-type’  is  same  as  previous  ’record-type’) 
if  (any  data  item  on  select-list  is  not 
defined  for  record-type) 
perform  error(2) 
return 
end-if 
else 

create  tgi-list  item  for  all  attributes 
of  record-type’  record 
for  (each  data  item  on  select-list) 
if  (’data-item’  not  on  move-list) 
perform  error)  1) 
return 
end-if 
else 

get  ’item-value’  from  move-list 
concat  "and  ('data-item'  =  ’item-value’)" 
to  abdl-str 
end-else 
end-for 

concat  ")(’tgt-list')  by  DBKEY  "  to  abdl-str 
connect  abdl-str  to  find  node 
end-else 
end-if 
else 

perform  error(6) 


The  FIND  Cl'RRENT  means:  Make  the  current  of  set-type  the  current 
record  of  the  run  unit.  * 


CURRENT  record-ivpe  WITHIN  set-tvpe 

{ 

if  (CIT. set-type. TYPE  is  not  equal  to  ’record-type') 
perform  error(7) 
return 
end-if 
else 

*  current  of  run-unit  becomes  current  of  'set-type'  */ 
alloc  and  init  new  Tind’  node 
find-type  =  CURRENT  in  find  node 
copy  record-type  to  find  node 
copy  set-type  to  find  node 
copy  ClT.set-t\ pe.dbkey  to  find  node 
end-else 
} 


The  FIND  DUPLIC.ATE  means:  Find  the  first  record  in  the  current  set- 
ype  occurrence  whose  value  for  iteml  through  itemn  matches  those 
for  the  same  items  in  the  current  set-type  occurrence,  not  the  U’\V.\  *  ' 
record  template.  This  implementation  assumes  the  records  being  re-  *, 
quested  are  already  in  a  buffer.  * 

DUPLIC.ATE  WITHIN  set-tvpe 

{ 

alloc  and  init  new  'find'  node 
find-type  -  DUPLICATE  in  find  node 
copy  set-type  to  find  node 
select-list  =  NULL  *  reset  select-list  */ 

} 

USlNCi  item-list  IN  record-tvpe 

{ 

if  ((record-type  is  not  CIT. set-type. TYPE)  or 
(record-type  is  not  ('IT.set-type./nember)) 
perform  error(8) 
return 
end-if 
else 

copy  record-type  to  find  node 
for  (each  data-item  on  select-list) 
if  (any  data-item  on  select-list  is  not 
defined  for  record-type) 
perform  error(‘d) 
ret  urn 
end-if 

else  *  create  a  pveudo  tgt-list 
cop)  data-item  to  find  node 
enil-else 
end-for 
end-else 


I 


This  statement  means;  Find  the  FIRST,  LAST,  NEXT,  or  PRIOR  record-  */ 
type  record  within  the  current  set-type  occurrence.  The  11  token  */ 
takes  the  value  FIRST,  LAST,  NEXT,  or  PRIOR.  */ 

II  record-type  WITHIN  set-type 

{ 

if  (’record-type’  is  not  a  valid  member  type 
for  ’set-type') 
perform  error(5) 
return 
end-if 
else 

copy  record-type  to  find  node 
copy  set-type  to  find  node 

*  RETRIEVE  all  member  records  of  set  occurrence  */ 

alloc  and  init  new  abdi-str 
alloc  and  init  new  tgt-Iist 
copy  "[RETRIEVE  ( 

(TEMPLATE  =  CIT. set-type. member)  and 
(MEMBER. set-type  =  ClT.set-type.owner-dbkey))" 
to  abdl-str 

create  tgt-list  for  all  attributes  of  member  record 
concat  "(’tgt-list’)  by  DBKEY;"  to  abdl-str 
connect  abdl-str  to  find  node 
end-etse 
} 

The  FIN’D  OWNER  means:  Find  the  owner  of  the  current  set-type  occurrence  */ 

OWNER  WITHIN  set-type 

{ 

alloc  and  init  ’find’  node 
find-type  =  OWNER  in  find  node 
copy  set-type  to  find  node 
alloc  and  init  new  abdl-str 
alloc  and  init  new  tgt-list 

/*  form  RETRIEVE  request  */ 

copy  "[RETRIf^VE  ((TEMPLATE  =  CIT, set-type. owner) 
and  (DBKEY  =  CIT.set-type.owner-dbkey))" 
to  abdl-str 

create  tgt-list  for  all  attributes  of  owner  record 
concat  "(’tgt-list’);"  to  abdl-str 
connect  abdl-str  to  find  node 


This  statement  means:  Find  the  first  record-type  record  within  the  ‘ / 
current  set-type  occurrence  whose  values  for  iteml  through  itemn  */ 
match  the  values  found  in  the  record-type  template  in  the  L'WA,  not  */ 
the  values  in  the  current  of  set-type  as  in  the  FIND  DL PLICATE.  */ 

I  record-type  WITHIN  set-type  CURRENT 

{ 

if  (’record-type’  not  a  member  type  of  ’set-type’) 
perform  error(5) 
return 
end-if 
else 

alloc  and  init  new  ‘find’  node 
find-type  =  W  ITHIN  in  find-node 
copy  record-type  to  find  node 
copy  set-type  to  find  node 
alloc  and  init  new  abdl-str 
alloc  and  init  new  tgt-list 

*  begin  forming  RETRIEVE  request  */ 

copy  "  RETRIEVE  ((TEMPLATE  =  ’record-type’)  and 
(MEMBER. set-type  =  CIT. set-type. owner-dbkey)" 
to  abdl-str 

create  tgt-list  for  all  attributes  of  ’record-type’ 
record 

select-list  =  NULL  /*  reset  select-list  */ 
end-else 
} 

USING  item-list  IN  record-type 

{ 

if  (any  data-item  on  select-list  is  not  defined 
for  ’record-type’) 
perform  error(2) 
return 
end-if 

else  if  (any  data-item  on  select-list 
not  on  move-list) 
perform  error(l) 
return 
end-else- if 
else 

for  (each  data-item  on  select-list) 
get  ’item-value’  from  move-list 
concat  "and  ('data-item’  =  ’item-value') 
to  abdl-str 
end-for 

concat  ")(’tgt-list’)  by  DBKEY ”  to  abdl-str 
connect  abdl-str  to  find  node 
end-else 


11:  FIRST 

{ 

alloc  and  init  new  Tind’  node 
find-type  =  FIRST  in  find  node 
} 

LAST 

{ 

alloc  and  init  new  'find’  node 
find-type  =  LAST  in  find  node 
} 

NEXT 

{ 

alloc  and  init  new  'find'  node 
find-tvpe  =  NEXT  in  find  node 
} 

PRIOR 

{ 

alloc  and  init  new  'find'  node 
find-tvpe  =  PRIOR  in  find  node 
} 


curr-suppression:  LSQL'ARE  supp-expr  RSQUARE 
empty 


supp-expr:  SUPPRESS  UPDATE 
UPDATE  type-spec 


type-spec;  set-type 

{ 

add  set-type  to  suppression-list 

} 

type-spec  COMMA  set-type 


add  successive  set-types  to  suppression-list 


This  statement  means:  Delete  the  current  record  of  the  run  unit,  */ 
and  all  of  its  descendents  regardless  of  whether  they  are  owners  of  */ 
other  sets.  */ 

se:  ERASE  ALL  record-type 

{ 

if  (’record-type’  is  not  CIT. RUN-UNIT. type) 
perform  error(3) 
return 
end-if 
else 

alloc  and  init  new  ’erase’  node 
erase-type  =  .\LL  in  erase  node 
for  (each  set-type  in  schema) 
if  (CIT. set-type. owner-dbkey  =  CIT. RUN-UNIT. dbkey) 
member-type  =  CIT.set-type. member 

/  *  form  RETRIEVE  to  get  member  records  */ 
alloc  and  init  new  abdl-str 

copy'''RETRlEVE(.’VfEMBER.set-type  =  CIT.RUN-UNIT.dbkey) 
(DBKEY)  by  DBKEY)"  to  abdl-str 
connect  abdl-str  to  erase  node 

/*  erase  member  records  */ 
alloc  and  init  new  abdl-str 

copy";DELETE((TEMPLATE  =  ’member-type’)  and 
(DBKEY  =  ***))]"  to  abdl-str 
connect  abdl-str  to  erase  node 

/*  delete  all  descendants  of  member  records  */ 
perform  erase-all(member-type, erase  node) 
end-if 
end-for 

/*  delete  current  of  RUN-UNIT  */ 
alloc  and  init  new  abdl-str 

copy  "[DELETE((TEMPLATE  =  ’record-type’)  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey)))"  to  abdl-str 
connect  abdl-str  to  erase  node 
end-else 


This  statement  means;  Delete  the  current  record  of  the  run  unit  if  */ 
and  only  if,  it  is  not  the  owner  of  a  non-empty  set.  */ 

ER.\SE  record-type 

if  (’record-type’  is  not  CIT. RUN-UNIT. type) 
perform  error(3) 
return 
end-if 
else 

*  erase  one  record  -  current  of  RUN-UNIT  */ 
alloc  and  init  new  ’erase’  node 

erase-type  =  NULL  in  erase  node 

*  form  RETRIEVE  to  see  if  ’record-type’  is  */ 

,  *  owner  of  non-empty  set  */ 

alloc  and  init  new  abdl-str 

copy  "  RETREIVEC  to  abdl-str 
first-time  =  TRUE 
for  (each  set-type  in  schema) 
if  (’record-type’  is  owner  type  of  set-type) 
if  (first-time) 

concat  "(MEMBER.set-type  =  CIT.RUN-UNIT.dbkey)" 
to  abdl-str 
first-time  =  F.\LSE 
end-if 
else 

concat  "or  (MEMBER.set-type  =  CIT.RUN-UNIT.dbkey)" 
to  abdl-str 
end-else 
end-if 
end-for 

concat  ")(DBKEY)  by  DBKEY  "  to  abdl-str 
connect  abdl-str  to  erase  node 

*  for  DELETE  request  */ 
alloc  and  init  new  abdl-str 

copy  "  DELETE  ((TE.MPLATE  =  CIT.RUN-UNIT.type)  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey));"  to  abdl-str 
connect  abdl-str  to  erase  node 
end-else 


/*  The  STORE  means:  Create  a  new  record  in  the  database  using  values  * 
supplied  by  the  user  via  MOVE  statements,  for  the  data  items  of  */ 

/*  the  specified  record-type.  The  is  connected  to  all  sets  in  which  */ 

/*  INSERTION  IS  AUTOMATIC.  The  appropriate  occurrence  of  the  sets  */ 

/*  must  be  selected  before  the  new  record  can  be  connected.  This  is  */ 

/*  done  based  on  the  SET  SELECTION  clause  specified  in  the  database  */ 

/*  schema  definition  for  the  sets  in  question.  */ 

store:  STORE  record-type 

{ 

if  (’record-ype’  record  template  node  is  not  on  move-list) 
perform  error(l) 
return 
end-if 

alloc  and  init  new  ’store’  node 
alloc  and  init  new  abdl-str 
copy  ":RETRIEVE  ("  to  abdl-str 
first-time  =  TRUE 

for  (each  data-item  in  schema  for  ’record-type’) 
if  (nan-dup-flag  is  set) 

if  (data-item  in  move-list  ’record-type’  record  template) 
get  data-item  value  from  move-list 
if  (first-time  =  TRUE) 
concat"((TEMPLATE  =  ’record-type’)  and 

(’data-item’  =  ’item-value’))"  to  abdl-str 
first-time  =  F.4LSE 
end-if 
else 

concat  "or  ((TE.MPLATE  =  ’record-type’)  and 

(’data-item’  =  ’item-value’))"  to  abdl-str 

end-else 

end-if 

end-if 

end-for 

concat")(DBKEY)  by  DBKEYj"  to  abdl-str 
connect  retrieve  request  to  store  node 
alloc  and  init  new  abdl-str 

/*  Form  an  INSERT  request  */ 

copy"  INSERT  (<TEMPLATE,’record-type’>,<DBKEY,***>"  to  abdl-str 
for  (each  ’data-item’  in  schema  for  ’record-type’) 
if  ('data-item’  not  on  move-list  for  ’record-type’) 
perform  error(4) 
return 
end-if 
else 

get  data-item  value  from  move-list 
concat", <’item-name’,’item-value’>"  to  abdl-str 
end-else 
end-for 


113 


*  The  MODIFY  means;  Modify  the  entire  current  record  of  the  run  unit 
/  *  or  the  specified  data  items  in  that  record.  The  new  values  are  */ 

/*  supplied  by  the  user  via  the  UWA.  */ 


modify:  MODIFY 

{ 

select-list  =  NULL  /*  reset  select-list  */ 

} 

item-list  IN  record-type 

{ 

if  (’record-type’  is  not  current  of  run  unit) 
perform  error(3) 
return 
end- if 

if  (’record-type’  record-template  node  is  not  on  move-list) 
perform  error(l) 
return 
end- if 

if  (any  data  item  on  select-list  not  defined  for  ’record-type’) 
perform  error(2) 
ret  urn 
end-if 
else 

alloc  and  init  new  ’modify’  node 

locate  record-template  node  on  move-list  for  ’record-type’ 
for  (each  data-item  on  select-list) 
alloc  and  init  new  abdl-str 
/*  form  UPDATE  request  */ 

copy  "I  UPDATE  ((TEMPLATE  =  ’record-type’)  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey))"  to  abdl-str 
get  ’item-value’  from  move-list 
concat  "(’data-item’  =  ’item-value’))"  to  abdl-str 
connect  abdl-str  to  ’modify’  node 
end-for 
end-else 


r.  4 


I 


I 

i 

I 

■ 

I 


MODIFY  record-type 

{ 

select-list  =  NULL  /*  reset  select-list  */ 
if  (’record-type’  not  current  of  run  unit) 
perform  error(3) 
return 
end-if 

if  (’record-type’  record-template  node  is  not  on  move-list) 
perform  error(l) 
return 
end-if 
else 

alloc  and  init  new  ’modify’  node 
for  (each  data-item  in  record-type) 
if  (data-item  not  on  move-list  for  ’record-type’) 
perform  yyerror(4) 
return 
end-if 
else 

alloc  and  init  new  abdl-str 

*  form  an  UPDATE  request  */ 
copy  "  UPDATE  ((TEMPLATE  =  ’record-type’)  and 
(DBKEY  =  CIT.RUN-UNIT.dbkey))  to  abdl-str 
get  new  ’item-value’  from  move-list 
concat  "(’data-item’  =  ’item-value’)]"  to  abdl-str 
connect  abdl-str  to  ’modify’  node 
end-else 
end-for 
end-else 
} 


The  CONNECT  means:  Connect  the  current  record  of  the  run  unit  to  the  */ 
current  occurrence  of  the  specified  set  type.  There  may  be  several  */ 

!*  sets  listed  in  the  statement.  */ 

connect;  CONNECT  record-type  TO 

{ 

if  (’record-type’  is  not  current  of  run  unit) 
perform  error(3) 
return 
end-if 
else 

alloc  and  init  connect-list 
end-else 
} 

set-type-list 

{ 

alloc  and  init  ’connect’  node 
for  (each  ’set-type’  on  connect-list) 
if  (’record-type’  is  not  a  member  type  record  for  ’set-type’) 
or  (INSERTION  is  not  manual) 
perform  error(5) 
return 
end-if 
else 

alloc  and  init  new  abdi-str 

copy  "'UPDATE  ((TEMPLATE  =  ’record-type’)  and 
(DBKEY  =  CIT  RUN-UNTT.dbkey)) 

(MEMBER. set-type  =  CIT.set-type.owner-dbkey))" 
to  abdl-str 

connect  new  abdi-str  to  ’connect’  node 
end-else 
end-for 

connect-list  =  NULL  /*  reset  connect-list  */ 

} 


set-type-list:  set-type 

{ 

add  ’set-type’  to  connect-list 

} 

set-type-list  COMMA  set-type 


add  successive  ’set-type’(s)  to  connect-list 

} 


*  The  DISCONNECT  means:  Disconnect  the  current  record  of  the  run  unit  */ 
,  *  from  the  set  type  occurrence  that  contains  the  record.  *, 


disconnect:  DISCONNECT  record-type  FROM 

{ 

if  (’record-type’  record  is  not  current  record  of  run  unit) 
perform  error(3) 
return 
end-if 
else 

alloc  and  init  new  connect-list 
end-else 
} 

set-type-list 

{ 

alloc  and  init  ’disconnect’  node 
for  (each  set-type  on  connect-list) 
if  (’record-type’  is  not  a  member  type  record  for  ’set-type’) 
perform  error(5) 
return 
end-if 
else 

alloc  and  init  new  abdl-str 

copy  "  LPD.^TE  ((TEMPLATE  =  ’record-type’)  and 
(DBKEY  =  ClT.RUN-UNIT.dbkey)) 
(.VlEMBER.set-type  =  NULL)j" 
to  abdl-str 

connect  abdl-str  to  ’disconnect’  node 
end-else 
end-for 

connect-list  =  NULL  /*  reset  connect-list  */ 

} 


perform-loop:  PERFORM  UNTIL  bb  EQ  cc 
END-PERFORM 


bb:  EOF 

NOTFOUND 


i 


cc:  YES 

NO 


ilem-list:  item-name 

{ 

put  item-name  on  select-list 

} 

I  item-list  COMMA  item-name 

{ 

put  successive  item  names  on  select-list 

} 


schema-name:  IDENTIFIER 


record-type:  IDENTIFIER 


set-type:  IDENTIFIER 


item-name:  IDENTIFIER 


item-value:  IDENTIFIER 
INTEGER 


proc  error(err-code) 

*  This  procedure  prints  error  messages,  causes  data  structures  to  *  / 

*  be  de-allocated.  and  causes  proc  yyerror  to  be  executed.  *  / 

case  err-code  of 

1:  print("Error  -  must  initialize  ’record-type’  record-template") 

2;  print("Error  -  ’data-item’  not  defined  in  ’record-type’") 

3:  print("Error  -  ’record-type’  is  not  current  record  of  run  unit") 

4;  print("Error  -  attempting  to  modify  or  store  record  without 
giving  value  of  ’data-item’") 

5:  print("Error  -  ’record-type’  record  does  not  belong  to  ’set-type’") 

6:  print("Error  -  record-types  specified  are  not  the  same") 

7:  print("Error  -  record-type’  is  not  current  of  set-type’") 

8:  print) "Error  -  'record-type’  must  be  a  member  record  of  ’set-type'") 
end-case 

perform  cleanup))  *  free  data  structures  *  ' 
perform  yyerror)) 
return 
end-error: 


▼ 


proc  by-application(abdl-str) 

if  (set-node  nsn-insert  -’a'  )  *  insertion  mode  is  automatic  *  ' 

concat",<MEMBER.set-type,ClT.set-type.owner-dbkey >"  to  abdl-str 
end-if 

else  I*  insertion  mode  is  manual  */ 
concat".<MEMBER.set-type,.NULL>"  to  INSERT  abdl-str 
end-else 

end-by-application; 


proc  by-value(abdl-str) 

locate  data-item  node  in  schema  for  set-select  node  item-name 
in  set-select  node  record  1 
if  (nan-dup-Bag  set) 

get  owner  record  type  of  set-type  from  schema 
if  (owner  record  type  node  not  on  move-list)  or 
(data-item  not  on  move-list) 
perform  error(4) 
return 
end-if 
else 

if  (set  node  nsn-insert  =  ’a  )  *  automatic  insertion  */ 

get  data-item  value  from  move-list 

copy"  RETR1EVE( (TEMPLATE  =  owner-record-type)  and 
(item-name  =  ’item-value’))  (DBKEY)  "  to  abdl-str 
connect  new  retrieve  request  to  store  node 
concat".<MEMBER.set-type.‘**>"  to  INSERT  abdl-str 
end-if 

else  *  manual  insertion  * 

concat",<MEMBER,set-type,NULL>"  to  INSERT  abdl-str 
end-else 
end-else 

end-if  '*  nan-dup-flag  */ 


end-bv-value: 


proc  by-structural(abdl-str) 

locate  data-item  nose  in  schema  for  set-select  node  item-name 
in  set-select  node  record  1  record-type 
if  (nan-dup-flag  set) 

get  recordl  name  from  set-select  node  for  set-type 
if  (  /ecordl’  record  template  node  not  on  move-list)  or 
(data-item  not  on  move-list) 
perform  error(4) 
return 
end-if 
else 

if  (set-node  nsn-insert  =  ’a')  /*  automatic  insertion  */ 
get  data-item  value  from  move-list 
get  record2  name  from  set-select  node  for  set-type 
copy"|RETRIEVE  ((TEMPLATE  =  records  name)  and 
(item-name  =  item-value))  (DBKEY)"  to  abdi-str 
connect  new  retrieve  request  to  store  node 
concat",<MEMBER. set-type, ***>"  to  INSERT  abdl-str 
end-if 

else  /*  manual  insertion  */ 

concat'',<MEMBER. set-type. NULL>''  to  INSERT  abdl-str 
end-else 
end-else 

end-if  /*  nan-dup>-flag  */ 
end-by-structural; 


proc  by-default(abdl-str) 

print("Warning  -  Attempting  to  store  a  record  with  no 
particular  set  selection  given.  Will  eissume  ’BY 
APPLICATION’") 

if  (set-node  nsn-insert  =  ’a’)  /*  automatic  insertion  *  j 
cone  at  ",<MEMBER.set-type,C  IT.se  t-type.owner-dbkey>" 
to  INSERT  abdl-str 
end-if 

else  /*  manual  insertion  */ 

cuncat",<MEMBER. set-type, NULL>"  to  INSERT  abdl-str 
end-else 


end-by-default: 


proc  erase-all(record-type, erase  node) 

string  member-type; 

for  (each  set-type  in  schema) 
if  (’record-type’  is  owner  type  of  set-type) 
member-type  =  member  type  of  set-type 
/*  for  RETRIEVE  to  get  members  of  ’set-type’  */ 
alloc  and  init  new  abdl-str 

copy  " ;RETRlEVE(MEMBER.set-type  =  ***)(DBKEY)  by  DBKEYJ 
to  abdl-str 

connect  abdl-str  to  erase  node 
/*  delete  member  records  */ 
alloc  and  init  new  abdl-str 

copy  "  DELETE((TEMPLATE  =  ’member-type’)  and  (DBKEY  = 
to  abdl-str 

connect  abdl-str  to  erase  node 
/*  erase  descendants  of  member  records  */ 
erase-all(member-type, erase  node) 
end-if 
end-for 

return(erase  node) 
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